ثغرة Rails الحرجة: قراءة ملفات الخادم عن بعد عبر CVE-2026-66066
ثغرة CVE-2026-66066 في Active Storage تسمح بقراءة ملفات الخادم، وتهدد بسرقة مفاتيح `secret_key_base` وبيانات الاعتماد الحساسة، مع تقييم CVSS 9.5.
مقدمة تحليلية
أفصحت Ruby on Rails عن تصحيحات لثغرة أمنية حرجة في Active Storage، وهي CVE-2026-66066، تحمل درجة خطورة 9.5 وفقاً لنظام CVSS. تسمح هذه الثغرة للمهاجمين غير المصادق عليهم بقراءة أي ملفات من خوادم التطبيقات عن طريق تحميل صور معدّة خصيصاً. تكشف الثغرة عن بيئة عملية Rails وأسرار حساسة مثل `secret_key_base`، مفتاح Rails الرئيسي، كلمات مرور قواعد البيانات، بيانات اعتماد التخزين السحابي، ورموز API، ما قد يتيح تنفيذ تعليمات برمجية عن بعد (RCE) أو الحركة الجانبية داخل الأنظمة المتصلة. التطبيقات المتأثرة تستخدم مكتبة libvips لمعالجة صور Active Storage وتقبل تحميل الصور من مستخدمين غير موثوق بهم.
تختار Rails مكتبة Vips افتراضياً ضمن إعدادات `load_defaults 7.0`، وتحتفظ بها الإصدارات الأحدث. الإصدارات المتأثرة تشمل Rails 7.0.0 حتى 7.2.3.1، و Rails 8.0.0 حتى 8.0.5، و Rails 8.1.0 حتى 8.1.3. كما تتأثر إصدارات Rails 6.0.0 حتى 6.1.7.10 فقط عندما يكون Active Storage مُعداً لاستخدام Vips، وهو ما لم يكن المعالج الافتراضي في تلك السلسلة. أكدت Ethiack وGMO Flatt Security هذه النطاقات.
يجب على المشغلين الترقية فوراً إلى Rails 7.2.3.2 أو 8.0.5.1 أو 8.1.3.1 وتدوير كل سر يمكن قراءته بواسطة عملية التطبيق. أشار GitHub repository لجهة خارجية في 29 يوليو 2026 إلى PoC يزعم تحقيق RCE كاملاً عبر Rails 8.1.3.
التحليل التقني
تكمن الآلية الأساسية للثغرة في استغلال معالجة الملفات داخل Active Storage و libvips. تستخدم عملية قراءة الملفات الأولية ملف MAT v7.3 مُعداً خصيصاً، وهو عبارة عن حاوية HDF5 تحتوي على مجموعة بيانات خارجية تشير إلى مسار ملف يحدده المهاجم. يبدأ حمولة الهجوم بسلسلة `MATLAB 5.0` الحرفية التي تتوقعها libvips، بينما يتسبب حقل الإصدار الخاص بها في معالجة libmatio للملف كـ HDF5 ومتابعة المرجع الخارجي.
مسار الهجوم واستغلال الثقة
على مسار التحميل المباشر، يقبل Active Storage حقل `content_type` الذي يوفره العميل، مما يسمح للمهاجم بتصنيف حمولة MAT كـ `image/png`. بعد ذلك، يمكن إعادة استخدام مفتاح تباين (variation key) مشروع ضد الكائن الثنائي الكبير الخبيث، مما يتسبب في معالجة Active Storage له باستخدام libvips وإرجاع بايتات الملف المستهدف عبر بكسلات الصورة المتولدة. تكمن الثغرة في حدود الثقة بين Active Storage و libvips. يشير الإشعار الأمني لـ Rails إلى أن libvips تدعم برامج تحميل وحفظ وعمليات أخرى، بعضها مدعوم بمكتبات طرف ثالث ومُسمى "غير مُختبر" (unfuzzed) أو "غير موثوق به" (untrusted) لأنها غير آمنة للإدخال الضار. لم يقم Active Storage بحظر هذه العمليات، مما سمح لتحميل مُعد خصيصاً باستدعاء واحدة منها والكشف عن الملفات التي يمكن لعملية Rails قراءتها. لا يتطلب التطبيق المُعرض للخطر كشف عملية مخصصة لتغيير الحجم أو إنشاء الصور المصغرة، حيث ذكر Rails أن "توليد المتغيرات ليس مطلباً منفصلاً". يُظهر التصحيح العام أن محلل ومحول Vips كلاهما مررا المرفقات غير الموثوق بها إلى العمليات غير الآمنة.
يمنح الطلب الناجح المهاجم أداة لقراءة الملفات العشوائية. أوضحت Ethiack أن سلسلة RCE الخاصة بها تستخدم هذا الوصول لاستعادة `secret_key_base` من بيانات الاعتماد المشفرة أو بيئة العملية، ثم صياغة مفتاح تباين خبيث، واستغلال `CVE-2025-24293`، حيث سمح محول Vips للمتغير المزور باستدعاء `instance_eval` وتنفيذ تعليمات Ruby البرمجية. يتطلب التصحيح استدعاء `Vips.block_untrusted(true)` عند بدء Active Storage. يمكن للتطبيقات التي لا تستطيع تحديث Rails فوراً تعيين `VIPS_BLOCK_UNTRUSTED` عند تشغيل libvips 8.13 أو أحدث، أو استدعاء `Vips.block_untrusted(true)` مع ruby-vips 2.2.1 أو أحدث. تقدم Rails أيضاً مجموعة أدوات للتحقيق الجنائي لتحديد مدى التعرض.
السياق وتأثير السوق
تتجاوز تداعيات هذه الثغرة مجرد قراءة الملفات؛ فالوصول إلى `secret_key_base` ومفاتيح قواعد البيانات ورموز API يمثل تهديداً مباشراً لاستمرارية الأنظمة الحيوية. على النقيض من التطبيقات التي تستخدم libvips، فإن التطبيقات التي تعتمد على MiniMagick لمعالجة الصور ليست عرضة لمسار الهجوم هذا تحديداً، ما يضع MiniMagick كبديل أكثر أماناً في هذا السيناريو. تغيرت مخاطر التعرض بشكل ملحوظ مع إصدار Rails 7.0.0 وما بعده، حيث أصبحت مكتبة Vips هي المعالج الافتراضي ضمن إعدادات `load_defaults 7.0`. هذا يعني أن الأنظمة الأحدث تكون أكثر عرضة للخطر افتراضياً مقارنةً بإصدارات Rails 6.x التي لم تكن تستخدم Vips كمعالج افتراضي، رغم أنها قد تتأثر إذا تم تكوينها يدوياً.
لم تكشف فرق البحث عن دليل على استغلال الثغرة قبل الكشف عنها أو بعده حتى تاريخ 29 يوليو 2026. هذا يتوافق مع عدم إدراج `CVE-2026-66066` في كتالوج CISA للثغرات المعروفة والمستغلة (Known Exploited Vulnerabilities catalog) اعتباراً من 27 يوليو 2026. تفتقر Rails إلى بيانات القياس عن بعد أو تقدير معقول لعدد التطبيقات التي تستخدم Active Storage مع Vips وتقبل تحميل صور غير موثوق بها، مما يترك فجوة كبيرة في فهم الحجم الحقيقي للمخاطرة. إن درجة CVSS البالغة 9.5 تصف شدة الثغرة، لا عدد عمليات النشر المعرضة لها؛ حيث يجب أن يكون النشر المعرض للخطر يستخدم Vips، ويقبل تحميل صور غير موثوق بها، ويتضمن عملية قابلة للاستغلال في بناء libvips الخاص به. تُضاف هذه الثغرة إلى سجل المراجعات الأمنية التي تتطلب تدقيقاً مستمراً، خصوصاً مع مساهمة Ethiack و GMO Flatt Security في الإبلاغ المستقل عنها.
رؤية Glitch4Techs
إن ثغرة CVE-2026-66066 ليست مجرد خطأ برمجي بسيط، بل هي إشارة واضحة إلى فشل أساسي في إدارة حدود الثقة ضمن تصميم Active Storage. كان السماح لـ Active Storage بتمرير مرفقات غير موثوق بها إلى عمليات libvips المصنفة بأنها "غير مُختبرة" أو "غير موثوق بها" منذ البداية يمثل إهمالاً تصميمياً صارخاً. هذا الخطأ يتفاقم بالنظر إلى أن المحول الخاص بـ Vips سمح لاحقاً باستغلال `CVE-2025-24293` عبر مفتاح تباين مزور لاستدعاء `instance_eval` وتنفيذ تعليمات Ruby برمجية، مما يحول قراءة الملفات الأولية إلى تنفيذ تعليمات برمجية عن بعد (RCE) بشكل كامل. إن مطالبة المطوّرين بتدوير كل سر يمكن قراءته بواسطة عملية التطبيق، بما في ذلك `secret_key_base` وكلمات مرور قواعد البيانات ورموز API، يؤكد على أن هذا ليس مجرد خطر جزئي بل هو اختراق شامل للثقة.
الاستنتاج لا مفر منه: هذا الإشراف الهندسي خلق سطح هجوم واسعاً، وكان قابلاً للاكتشاف والتصحيح في مراحل التصميم المبكرة.
كن أول من يعرف بمستقبل التقنية
أهم الأخبار والتحليلات التقنية مباشرة في بريدك.
