في تحديث أمني عاجل، أصدر فريق Ruby on Rails تصحيحات لثغرة حرجة (CVE-2026-66066 بتقييم CVSS عند 9.5) في مكون Active Storage، تسمح للمهاجمين غير المصادقين بقراءة ملفات عشوائية من الخادم، وكشف أسرار حساسة مثل secret_key_base ومفاتيح الاعتماد. ويُمهد هذا الاختراق الطريق لتنفيذ أوامر برمجية عن بُعد أو الانتقال لاختراق أنظمة أخرى ضمن الشبكة.
تستهدف الثغرة التطبيقات التي تعتمد على مكون Active Storage بالتزامن مع استخدام مكتبة libvips لمعالجة الصور، خاصة تلك التي تقبل تحميل صور من مستخدمين غير موثوقين. وتتأثر بهذا الخلل إصدارات محددة تشمل: (7.0 حتى 7.2.3.1)، و(8.0.0 حتى 8.0.5)، و(8.1.0 حتى 8.1.3). كما يُحتمل أن تتأثر إصدارات 6.x في حال تخصيص إعداداتها. ونظراً لأن Vips هو معالج الصور الافتراضي في إصدارات Rails 7.0 وما بعدها، فإن العديد من التطبيقات تعد عرضة للهجوم مباشرة دون الحاجة إلى تكوينات خاصة.
يكمن السبب الجذري للثغرة في أن Active Storage لم يقم بتعطيل ما يُعرف بـ “العمليات غير الآمنة” (unfuzzed operations) في مكتبة libvips قبل الشروع في معالجة الملفات المرفوعة من المستخدمين. تستخدم هذه العمليات، المدعومة بمكتبات خارجية، لتحميل وحفظ صيغ صور معينة، إلا أنها مصممة حصراً للتعامل مع المحتوى الموثوق. يستغل المهاجم هذا الضعف عبر تحميل ملف يُوهم مكتبة libvips بأنه ملف MATLAB من المستوى 5، في حين تتعامل معه مكتبة libmatio على أنه حاوية HDF5 من النوع MAT 7.3. ومن خلال استغلال قائمة الملفات الخارجية في بنية HDF5، يتمكن المهاجم من قراءة أي ملف يمتلك التطبيق صلاحية الوصول إليه، ليتم عرض محتوياته لاحقاً على شكل بكسلات صورة تُرسل ضمن استجابة الخادم.
ولضمان نجاح هذا الهجوم، يُشترط أن يكون مسار الرفع المباشر في Active Storage متاحاً للوصول. يذكر أن هذا المسار يكون موجوداً بشكل افتراضي عند تحميل مسارات المكون، حتى وإن كانت واجهة التطبيق الفعلية لا تستخدمه. كما يتطلب الهجوم وجود عملية matload ضمن بناء مكتبة libvips المُستخدمة.
أكدت شركة Rapid7، من خلال تحليلها الفني، أن مرحلة قراءة الملفات العشوائية تتم دون الحاجة إلى معرفة مسبقة بمفتاح secret_key_base أو اللجوء لتزوير مفتاح التغيير. وتحققت الشركة أيضاً من إمكانية تصعيد الهجوم وصولاً إلى تنفيذ أكواد عن بُعد عبر تزوير مفتاح توقيع Rails لاستغلال إصدارات ImageProcessing 1.x، وذلك بالاستغناء عن الحاجة إلى إلغاء تسلسل Marshal.
أما على صعيد الاستغلال الفعلي، فلم ترصد Rapid7 أي هجمات حقيقية حتى تاريخ 30 يوليو 2026. لكن في 31 يوليو، تمكن عدة باحثين مستقلين من إجراء هندسة عكسية للهجوم ونشر أكواد إثبات المفهوم (PoC). هذا التطور السريع دفع فريق Rails إلى التعجيل بنشر التفاصيل التقنية وأدوات التحليل الجنائي، وهو ما كان مقرراً في الأصل بتاريخ 28 أغسطس. بناء على ذلك، يُنصح مسؤولو التطبيقات ببدء إجراءات التقييم على الفور، نظراً لأن عمليات التنظيف الدورية للملفات غير المرتبطة قد تؤدي إلى مسح أدلة الاختراق.
اكتشفت هذه الثغرة جهتين مستقلتين هما فريق Ethiack الذي يضم (André Baptista، Bruno Mendes، Rafael Castilho)، وفريق GMO Flatt Security ممثلاً بالباحث (RyotaK). وقد جرى التنسيق بين الفرق لإصدار التصحيحات اللازمة.
للتخفيف من مخاطر الثغرة، يجب الترقية إلى الإصدارات المصححة من Active Storage وهي: 7.2.3.2، و8.0.5.1، و8.1.3.1، مع ضرورة ترقية مكتبة libvips إلى الإصدار 8.13 أو ما يليه، حيث تفتقر الإصدارات الأقدم لدعم ميزة تعطيل العمليات غير الآمنة. وفي الحالات التي يتعذر فيها إجراء الترقية الفورية، يمكن تفعيل طبقة حماية مؤقتة من خلال ضبط المتغير البيئي VIPS_BLOCK_UNTRUSTED، أو استدعاء الأمر Vips.block_untrusted(true) من مُهيئ التطبيق، وذلك عند استخدام إصدار ruby-vips 2.2.1 فما فوق.
وتشدد إرشادات Rails الأمنية على أن عملية الترقية تسد الثغرة لكنها لا تعالج تداعيات أي تسريب سري قد حدث بالفعل؛ لذا يحتم الموقف تغيير جميع الأسرار التي يمكن للتطبيق قراءتها، ويشمل ذلك المفتاح الرئيسي وبيانات اعتماد قواعد البيانات وخدمات التخزين.
