قام Redis بشحن سبعة إصدارات أمنية في 23 يوليو بعد أن نشر الباحثون إثباتات المفهوم (RCE) الموثقة للمخزون Redis 6.2.22 و7.4.9 و8.6.4 و8.8.0.
تتطلب جميع السلاسل الأربع استعادة. تحتاج سلاسل التدفقات أيضًا إلى EVAL وXGROUP؛ تحتاج السلسلة 8.8.0 إلى EVAL ووحدة RedisBloom المجمعة. يقول Redis الذاكرة الأساسية قد تؤدي العيوب إلى تنفيذ التعليمات البرمجية عن بعد.
تعمل إصدارات Redis 6.2.23 و7.2.15 و7.4.10 على إصلاح التدفقات المشتركة-NACK التي تستخدم بعد الاستخدام مجانًا؛ يعمل Redis 8.2.8 و8.4.5 و8.6.5 على إصلاح مشكلة التدفقات وعمليات الكتابة خارج الحدود لـ RedisBloom وTDigest؛ يعمل Redis 8.8.1 على إصلاح أدوات التحميل RedisBloom وTDigest، بينما كان Streams Guard موجودًا بالفعل في Redis 8.8.0.
اثنان من أهداف PoC، Redis 6.2.22 و7.4.9، هما التحديثات الأمنية لشهر مايو التي طلب Redis من المستخدمين تثبيتها، لكن هذه الإصدارات لم تتضمن حارس ملكية NACK المشترك.
الترقية إلى الإصدار الثابت للفرع المنشور. وحتى ذلك الحين، قم بإلغاء عملية الاستعادة من الحسابات التي لا تحتاج إليها بشدة وقم بحظر الوصول غير الموثوق إلى الشبكة. يؤدي تقييد الاستعادة إلى قطع كلا المسارين اللذين تم الكشف عنهما.
لم تتم مراجعة مذكرات إصدار Redis بتاريخ 23 يوليو ولا مستودعات إثبات المفهوم (PoC) العامة التي تمت مراجعتها بشأن الاستغلال الفعلي المُبلغ عنه اعتبارًا من 24 يوليو 2026.
طريقان من خلال الاستعادة
يعد مسار Redis Streams خطأً في الملكية المشتركة. يمكن أن يؤدي كائن RDB التالف إلى قيام مستهلكين اثنين بالإشارة إلى نفس سجل الإدخال المعلق، لذا فإن إزالة كلا المستهلكين تؤدي إلى تحرير نفس الكائن مرتين.
تم تصميم البرنامج النصي المنشور لتحويل تلف الذاكرة الناتج إلى وصول عشوائي للذاكرة واستدعاء النظام () في النهاية.
مسار RedisBloom عبارة عن كتابة خارج الحدود في محمل TDigest RDB. قام المُحمل بتخصيص الذاكرة من قيمة متسلسلة واحدة ولكنه يثق في حقل سعة منفصل يتحكم فيه المهاجم عند تحديد مقدار البيانات التي سيتم تحميلها.
تم تصميم البرنامج النصي Redis 8.8.0 لتحويل عدم التطابق هذا إلى عناصر أولية للقراءة والكتابة، وتسريب عناوين Redis وlibc، واستدعاء النظام ().
سلسلة التدفقات المشتركة NACK
المسار الأول موجود في Redis Streams. يمكن لكائن RDB التالف أن يجعل اثنين من المستهلكين يشيرون إلى نفس سجل الإدخال المعلق، والذي يتم تمثيله داخليًا بواسطة StreamNACK. تؤدي إزالة المستهلك الأول إلى تحرير الكائن وترك المستهلك الثاني يحمل مؤشرًا متدليًا. تقوم البرامج النصية بعد ذلك بإزالة المستهلك الثاني أيضًا. قطعة واحدة، قطعتان مجانيتان.
تشير ملاحظات إصدار Redis 8.6.4 إلى PR #15081. لكن مراجعة المصدر بواسطة The Hacker News وجدت أن المصدر 8.6.4 الموسوم يفتقر إلى التحقق من الملكية المكررة الذي أضافه هذا التغيير. يظهر الحارس في Redis 8.6.5، الذي تم إصداره في 23 يوليو.
تم تصميم البرنامج النصي Redis 8.6.4 المنشور لتحويل الإصدار المزدوج إلى وصول عشوائي إلى الذاكرة، ثم تسميم وظيفة تجزئة قاعدة البيانات بحيث تستدعي GET المصممة النظام (). يقوم باستعادة المؤشر والتحقق مما إذا كان Redis لا يزال يستجيب.
سلسلة RedisBloom TDigest
يقع المسار الثاني في محمل RedisBloom TDigest RDB. لقد خصصت مصفوفاتها المركزية من قيمة ضغط متسلسلة، ثم وثقت في حقل سعة منفصل يتحكم فيه المهاجم عند تحديد عدد العقد التي يمكن تحميلها. يؤدي التخصيص الحقيقي الصغير المقترن ببيانات التعريف المتضخمة إلى كتابة خارج الحدود.
تم تصميم البرنامج النصي Redis 8.8.0 لتحويل الكتابة إلى عناصر أولية للقراءة والكتابة، وتسريب عناوين Redis وlibc، وتسميم وظيفة تجزئة قاعدة البيانات، لذا يستدعي GET النظام(). نشر إثبات منفصل للمفهوم نفس السبب الجذري وسلسلة RCE موثقة ضد Redis 8.8.0.
يتطلب إصلاح Redis لشهر يوليو سعة TDigest المحملة لمطابقة التخصيص المشتق من قيمة الضغط. كما أنه يحد من عدادات العقدة المدمجة وغير المدمجة قبل قراءة المصفوفات.
سبعة إصدارات، لا توجد سجلات جديدة لمكافحة التطرف العنيف
يستدعي المستودع جزء إصدار التدفقات من CVE-2026-25589 “عائلة الإصلاح غير المكتملة”، لكن Redis يعين CVE إلى تلف ذاكرة RedisBloom أثناء الاستعادة، وليس عيب Streams Shared-NACK. لا تتضمن ملاحظات إصدار Redis لشهر يوليو أي نقاط CVE أو CVSS لأي من فئتي الأخطاء الجديدتين.
اعتبارًا من 24 يوليو، لم تجد عمليات البحث التي أجرتها The Hacker News أي سجل NVD منفصل لنتائج NACK المشتركة أو TDigest لشهر يوليو. لا تزال NVD تدرج سجلات شهر مايو لـ CVE-2026-25243 وCVE-2026-25589. لم يُرجع البحث في كتالوج الثغرات الأمنية المستغلة المعروفة التابع لـ CISA أي إدخال لأي من المعرفين.
يأتي هذا الكشف في أعقاب خلل آخر في Redis RCE تم اكتشافه بواسطة الذكاء الاصطناعي في مايو. تصف Bera Buddies نفسها بأنها “أبحاث وكيل الذكاء الاصطناعي”. قال Chaofan Shou على X إن عملاء Kimi K3 عثروا على 19 يومًا صفرًا لـ Redis في حوالي 90 دقيقة، وقالوا إن تشغيلًا آخر أنتج استغلال Redis 8.8.0 في 27 دقيقة.
تظل هذه التعدادات والتوقيتات ودرجة الاستقلالية المزعومة يتم الإبلاغ عنها ذاتيًا. يؤكد سجل Redis العام على العيوب والإصلاحات. ولا يتحقق من صحة عدد يوم الصفر المطالب به أو مدى استقلالية عمل العملاء.
Redis 6.2.22 و7.4.9 كانت وجهة مايو. وبحلول يوليو/تموز، كان كلاهما بحاجة إلى تحديث آخر. تحقق من إصدار الفرع الدقيق، وليس ما إذا كان Redis مجرد “تم تصحيحه مؤخرًا”.
