ثغرات ريديس الخطيرة دفعت الشركة إلى طرح 7 تحديثات أمنية في 23 يوليو، بعد نشر نماذج استغلال قد تقود إلى تنفيذ أوامر عن بعد RCE.
ما هي ثغرات ريديس التي أثارت التحذير الأمني؟
أطلقت Redis حزمة تحديثات أمنية واسعة بعد كشف سلاسل هجوم تستهدف الإصدارات 6.2.22 و7.4.9 و8.6.4 و8.8.0. الخطورة هنا لا تتعلق بعطل نظري، بل بمسارات استغلال منشورة يمكنها تحويل أخطاء الذاكرة إلى سيطرة فعلية على الخادم.
وبحسب ما رصدته تيكبامين، فإن جميع سلاسل الهجوم المعلنة تعتمد على صلاحية RESTORE. بعض المسارات تحتاج أيضا إلى EVAL وXGROUP، بينما يتطلب أحدها في Redis 8.8.0 وجود وحدة RedisBloom المدمجة.
لماذا تعد المشكلة حساسة للمؤسسات؟
تكمن الحساسية في أن الخلل يظهر في نسخ Redis القياسية المستخدمة على نطاق واسع داخل تطبيقات الويب والمنصات السحابية. وإذا كانت الصلاحيات أو الوصول الشبكي غير مضبوطين، فقد ترتفع المخاطر بسرعة.
- الإصدارات المتأثرة: 6.2.22 و7.4.9 و8.6.4 و8.8.0
- نوع الخطر: تنفيذ أوامر عن بعد RCE بعد استغلال أخطاء ذاكرة
- الصلاحية المشتركة بين المسارات: RESTORE
- صلاحيات إضافية لبعض السلاسل: EVAL وXGROUP
كيف يعمل استغلال ثغرات ريديس عبر Streams؟
المسار الأول يضرب Redis Streams من خلال خلل ملكية مشتركة داخل سجل pending-entry. يمكن لملف RDB خبيث أن يجعل مستهلكين مختلفين يشيران إلى نفس الكائن الداخلي، ما يقود في النهاية إلى تحرير الذاكرة مرتين.
بعد ذلك، يحاول كود الاستغلال تحويل فساد الذاكرة إلى قراءة وكتابة تعسفية داخل الذاكرة، ثم استدعاء system(). هذا النوع من الاستغلال يعد أخطر من مجرد تعطل الخدمة لأنه يفتح الباب أمام تنفيذ أوامر على النظام نفسه.
ما الذي أصلحته التحديثات؟
- Redis 6.2.23 و7.2.15 و7.4.10 تعالج مشكلة Streams shared-NACK
- Redis 8.2.8 و8.4.5 و8.6.5 تعالج مشكلة Streams إضافة إلى عيوب RedisBloom وTDigest
- Redis 8.8.1 يعالج محملات RedisBloom وTDigest
هل توجد ثغرة أخرى في RedisBloom وTDigest؟
نعم، المسار الثاني يرتبط بوحدة RedisBloom وبشكل أدق مع محمل TDigest داخل ملفات RDB. الخلل ناتج عن تخصيص ذاكرة اعتمادا على قيمة، ثم الوثوق بسعة مختلفة يتحكم بها المهاجم عند تحميل البيانات.
هذا التناقض يسمح بكتابة خارج الحدود المخصصة، وهو ما يمكن أن يتحول إلى أدوات للقراءة والكتابة داخل الذاكرة ثم تسريب عناوين Redis وlibc، وصولا إلى استدعاء system().
- المشكلة الأساسية: out-of-bounds write
- الهدف النهائي للمهاجم: الوصول إلى تنفيذ أوامر على الخادم
- النسخة 8.8.1 جاءت لإغلاق هذا المسار تحديدا
ماذا يجب على المستخدمين فعله الآن لحماية ريديس؟
الخطوة الأولى هي الترقية الفورية إلى النسخة المصححة ضمن الفرع المستخدم في بيئة العمل. وإذا تعذر ذلك مؤقتا، فيجب سحب صلاحية RESTORE من الحسابات غير الضرورية ومنع أي وصول شبكي غير موثوق إلى الخوادم.
حتى 24 يوليو 2026، لم تظهر دلائل عامة على استغلال واسع لهذه الثغرات في الهجمات الفعلية، لكن ذلك لا يقلل من خطورتها. ولهذا ترى تيكبامين أن التعامل السريع مع ثغرات ريديس أصبح أولوية لأي فريق يدير بنية تعتمد على Redis في الإنتاج.
