أطلقت روبي أون ريلز تحديثات أمنية لمعالجة ثغرة وُصفت بأنها بالغة الخطورة داخل مكوّن التخزين النشط للوسائط (Active Storage) عند استخدام مكتبة Vips لمعالجة الصور. التحديثات ترتبط بالمعرّف ‏CVE-2026-66066 وبدرجة خطورة 9.5 وفق مقياس CVSS، وهي درجة عادةً ما تعني أن الثغرة قد تسمح لخصم غير مصادق باختراق حدود الثقة بين مكوّنات التطبيق، والانتقال من قراءة ملفات تعسفية إلى احتمالات أوسع مثل كشف بيئة العملية وما تحتويه من مفاتيح وبيانات اعتماد.

ما يجعل هذه الحالة مهمة لقطاع واسع من المؤسسات ليس فقط “قوة” الثغرة من منظور تقني، بل طبيعة المسار: فالهجوم يبدأ غالبًا من شيء مألوف للمستخدمين—رفع صورة—ثم يستغل ثغرة في كيفية تعامل النظام مع صيغ/محملات غير موثوقة داخل سلسلة معالجة الصور، ليُفضي في النهاية إلى كشف أسرار حساسة.

ما الذي يحدث بالضبط؟ فهم حدود الثقة بين التخزين النشط وVips

في التطبيقات التي تستخدم Active Storage لمعالجة الصور، قد تُطبَّق عمليات مثل إنشاء “النسخ المتغيرة” (Variants) أو تحليل الصور أو تحويلها إلى أحجام متعددة. المشكلة هنا أن Vips (عبر libvips وruby-vips إن وُجد) يدعم وظائف تحميل/حفظ وصيغًا متعددة، وبعضها مُعلَّم داخليًا على أنه غير آمن أو “غير موثوق” عند التعامل مع مدخلات عدائية.

بحسب إرشادات أمان روبي أون ريلز، فإن Active Storage لم يَحجب هذه العمليات غير الآمنة عند استقبال ملفات صور من مستخدمين غير موثوقين. النتيجة: يمكن لطلب مُصاغ بدقة أن يستدعي عملية داخل Vips تُتيح للخصم مبدأ قراءة ملفات تعسفية—أي القدرة على قراءة ملفات يملكها مستخدم تشغيل عملية التطبيق—ومن ثم قد تتطور القدرة إلى تنفيذ تعليمات أو حركة جانبية، اعتمادًا على ما يتم استخراجه من أسرار.

للتوضيح: قراءة الملفات تعسفيًا لا تعني بالضرورة “تنفيذًا مباشرًا” دائمًا، لكنها ترفع قيمة الهجوم جذريًا لأنها قد تكشف معلومات حساسة مثل:

• secret_key_base (مفتاح توقيع/تشفير في ريلز)
• مفاتيح ريلز الرئيسية أو المفاتيح المماثلة
• كلمات مرور قاعدة البيانات وملفات الإعدادات
• اعتمادات خدمات التخزين السحابي (مثل رموز الوصول)
• رموز واجهات برمجية (API tokens)

هذه الأسرار قد تفتح الباب أمام سيناريوهات مثل استغلال جلسات أو انتحال أو حتى تنفيذ تعليمات عن بُعد إذا توافرت مفاتيح/سياقات تسمح بذلك، أو إذا كانت هناك مسارات تكامل داخلية يمكن الوصول إليها بعد الحصول على بيانات اعتماد.

للمزيد من الخلفية حول مفهوم استغلال حدود الثقة في البرمجيات، يمكنك مراجعة حدود الثقة (Trust boundary)، وحول مفهوم قراءة الملفات غير المصرح بها عبر الثغرات انظر اجتياز المسار (Path traversal) (رغم أن المسار هنا مختلف، إلا أن الفكرة العامة لكسر قيود الوصول وثيقة الصلة).

من هم الأكثر عرضة؟ لماذا “رفع صورة” قد يصبح نقطة دخول

الشرط الحاسم في هذه الثغرة هو اجتماع عدة عوامل:

• استخدام Active Storage مع معالج صور يعتمد Vips (عبر libvips).
• قبول التطبيق لرفع صور من مستخدمين غير موثوقين (أي لا تُعامل المدخلات على أنها آمنة).
• وجود إصدار من روبي أون ريلز ضمن النطاقات المتأثرة قبل الإصلاح، وبناء Vips الذي لا يمنع العمليات غير الآمنة.

من المهم أيضًا ملاحظة أن الهجوم لا يتطلب بالضرورة وجود زر “تغيير الحجم” أو “إنشاء مصغرات” كوظيفة منفصلة. بحسب توضيح روبي أون ريلز، فإن Generating variants ليست شرطًا منفصلًا بحد ذاتها؛ فالأمر يتعلق بتمرير مرفقات غير موثوقة إلى عمليات داخل Vips، سواء كان ذلك عبر محلل الصور أو المُحوّل (transformer).

هذا النمط شائع في هجمات الويب الحديثة: نقطة الدخول تبدو “سطحية” (رفع ملف)، لكن المشكلة تكون في سلسلة المعالجة داخل الخلفية حيث تفقد التطبيقات السيطرة على الافتراضات الأمنية حول المدخلات.

ما نطاق الإصدارات المتأثرة؟ وكيف يختلف الأمر باختلاف الإعدادات

تم تحديد الإصدارات المتأثرة على النحو التالي (وفق ما ورد في التقارير الفنية):

• روبي أون ريلز 7.0.0 إلى 7.2.3.1
• روبي أون ريلز 8.0.0 إلى 8.0.5
• روبي أون ريلز 8.1.0 إلى 8.1.3

بالنسبة لـ روبي أون ريلز 6.x، فقد تكون الإصدارات التالية متأثرة فقط عند تفعيل Vips كمعالج للصور (بينما لم يكن Vips افتراضيًا في ذلك الجيل):

• 6.0.0 إلى 6.1.7.10 بشرط تهيئة Active Storage لاستخدام Vips

في المقابل، التطبيقات التي تستخدم MiniMagick لا تنطبق عليها نفس مسارات الهجوم المرتبطة بهذه الثغرة تحديدًا، لأن المسار التقني يعتمد على Vips.

أما ريلز 7.1 وما قبلها ضمن حدود الدعم، فتنطبق عليها قاعدة خطيرة عمليًا: إن لم تكن ضمن نافذة الدعم، فلن تحصل على ترقيعات رجعية (backports)، ما يعني أن التخفيف الأساسي هو الترقية.

كيف يبدو “مسار الهجوم”؟ من قراءة الملفات إلى احتمال تنفيذ التعليمات

لم تُنشر إثباتات مفهوم رسمية (PoC) من فرق الباحثين في وقت مبكر من الإعلان. ومع ذلك، ظهر لاحقًا—وفق التحديثات—مستودع طرف ثالث على GitHub يدّعي إعادة إنتاج سلسلة الهجوم كاملة في بيئة معزولة داخل حاوية (Docker lab) مع استخدام إصدار “مُقارن” بين نسخة مصححة وأخرى غير مصححة.

لا تُعد هذه الادعاءات بحد ذاتها دليلًا قاطعًا على قابلية الاستغلال في كل البيئات، لكن وجود مثل هذا المسار يعكس حقيقة أمنية: عندما تحصل على قراءة ملفات تعسفية داخل سياق عملية تطبيق ويب، فإنك غالبًا تحصل على مفاتيح يمكن أن تُترجم إلى قدرات أوسع.

وفق التقارير، تتضمن السلسلة عناصر مثل:

• رفع ملف بصيغة مُصاغة لاستدعاء عملية غير آمنة داخل Vips.
• استخراج معلومات من بيئة العملية (process environment).
• استعادة SECRET_KEY_BASE أو ما يماثله.
• توقيع حمولة داخلية (Marshal payload) ثم إطلاق طلب خارجي للتحقق من النتيجة (out-of-band callback).

الجزء الحاسم هنا هو أن التنفيذ عن بعد أو الحركة الجانبية ليست “مضمونة تلقائيًا”، لكنها تصبح أكثر احتمالًا عندما تتوفر الأسرار والقدرات اللازمة.

الإجراءات المطلوبة: ترقية روبي أون ريلز وتقييد Vips وتدوير الأسرار

توصيات المعالجة جاءت واضحة من جهة فريق أمان روبي أون ريلز:

1) الترقية إلى إصدارات مصححة

• روبي أون ريلز 7.2.3.2 أو أحدث
• روبي أون ريلز 8.0.5.1 أو أحدث
• روبي أون ريلز 8.1.3.1 أو أحدث

2) تحديث libvips وruby-vips

تتطلب التثبيتات المصححة على مستوى Vips الوصول إلى:

• libvips 8.13 أو أحدث
• وعند تثبيت ruby-vips: ruby-vips 2.2.1 أو أحدث

3) تفعيل حظر العمليات غير الموثوقة

التصحيح يفعّل دالة حظر في Vips عند بدء Active Storage عبر Vips.block_untrusted(true). إذا تعذرت الترقية الفورية لروبي أون ريلز، يمكن—وفق الإرشادات—استخدام متغير بيئة لتقييد السلوك في Vips عند توفر الإصدار المناسب.

لكن نقطة لا بد من إبرازها: إذا كانت إصدارات libvips أقدم من الحد الذي يدعم الحظر، فلن تنجح هذه الخطوة كبديل. عندها يصبح تحديث libvips أو إزالة الاعتماد على Vips خيارًا استراتيجيًا لا يمكن تأجيله.

4) تدوير كل سر يمكن قراءته

حتى إن لم يكن هناك دليل على استغلال فعلي، فإن منطق الأمن الحديث يفرض التعامل مع الثغرة كاحتمال تعرض. توصي روبي أون ريلز بتدوير:

• secret_key_base
• مفاتيح ريلز الرئيسية والبيانات المشفرة/المفكوكة
• اعتمادات قاعدة البيانات
• مفاتيح وخدمات Active Storage
• رموز الطرف الثالث وواجهات API

هذه الخطوة تتماشى مع أفضل الممارسات في إدارة الحوادث: عندما يكون هناك احتمال لاستخراج أسرار من مساحة عملية التطبيق، فإن “إصلاح الثغرة” وحده لا يكفي. يجب افتراض أن الأسرار قد تسربت.

لماذا قد تفشل المؤسسات في اكتشاف التعرض؟ فجوة الرصد والقياس

وفق ما نُقل، لا تمتلك روبي أون ريلز—على ما يبدو—قياسات أو “تليمتري” موثوق يتيح تقدير عدد التطبيقات التي تستخدم Active Storage مع Vips وتقبل رفع صور غير موثوقة. هذا شائع في العالم الحقيقي: كثير من المؤسسات لا تمتلك جردًا دقيقًا للتبعيات (dependencies) ولا تملك رؤية إلى كيفية تهيئة مكتبات معالجة الصور في بيئات الإنتاج.

ولأن الثغرة تعتمد على سلسلة معالجة محددة، قد لا تظهر في سجلات “محاولات” واضحة، خصوصًا إن كانت الهجمات منخفضة التكرار أو تستهدف مسارات محددة داخل التطبيق.

لذلك، ينصح فريق الأمان عادةً بـ:

• فحص ملفات التهيئة بحثًا عن استخدام Vips ضمن Active Storage.
• تحديد الإصدارات الدقيقة لـ libvips وruby-vips.
• ربط ذلك بترقية روبي أون ريلز إلى إصدارات مصححة.
• تنفيذ تدوير أسرار على الأقل تلك التي تُستخدم لتوقيع/تشفير أو الوصول إلى قواعد البيانات والتخزين السحابي.

صلة هذه الحادثة باتجاهات أوسع: ثغرات “المعالجة” تتصدر

إذا نظرنا إلى المشهد الأوسع، نجد أن ثغرات معالجة الملفات—وخاصة الصور والمستندات—تستمر في الظهور كفئة عالية الخطورة. السبب بسيط: أنظمة مثل Vips وImageMagick وPDF parsers وغيرها تعمل كجسر بين مدخلات المستخدمين وبين مكتبات قد تتضمن محملات وصيغًا “غير آمنة” عند إساءة استخدامها.

وهذا ينعكس في اتجاهات الصناعة نحو:

• تطبيق مبدأ التحقق الصارم من المدخلات (input validation) حتى عند وجود آليات معالجة داخلية.
• تقليل سطح الثقة في مكونات المعالجة عبر تفعيل “حظر غير الموثوق”.
• التركيز على إدارة التبعيات وتحديثها بسرعة، لأن المكتبات الخارجية قد تحمل منطقًا معقدًا.
• ربط إدارة الثغرات بعمليات تدوير الأسرار وليس فقط بالترقيع (patching).

لربط ذلك بإطار عمل شائع في الصناعة، يمكنك مراجعة إطار عمل نِست للأمن السيبراني (NIST Cybersecurity Framework)، خصوصًا محاور “تحديد” و”الاستجابة” و”الاستعادة”، أو الاطلاع على CVSS لفهم معنى الدرجات بشكل أعمق.

هل ظهرت عمليات استغلال فعلية؟ وما الذي نعرفه حتى الآن؟

حتى تاريخ الإعلان، لم تكن روبي أون ريلز—وفق التصريحات المنسوبة—تملك علمًا بوقوع استغلال قبل أو بعد الكشف. كما تم فحص قوائم المعروف استغلاله (CISA Known Exploited Vulnerabilities) ولم يظهر إدراج الثغرة في نسخة محددة من الكتالوج في وقت المراجعة.

لكن غياب الأدلة لا يعني غياب المخاطر. كثير من الفاعلين يستغلون ثغرات “غير مصنفة بعد” أو يختبرونها بهدوء قبل التصعيد. لذا، أفضل استراتيجية للمؤسسات هي التعامل مع الثغرة كتهديد نشط احتمالي، لا كخبر تقني فقط.

ما الذي يجب أن تفعله فرق تقنية المعلومات اليوم؟

• تحديد ما إذا كان تطبيقك يستخدم Active Storage مع Vips، وليس فقط “وجود مكتبة الصور” بشكل عام.
• ترقية روبي أون ريلز إلى الإصدارات المصححة المذكورة.
• تحديث libvips وruby-vips إلى الإصدارات التي تدعم حظر غير الموثوق.
• تدوير الأسرار الحساسة التي يمكن للتطبيق قراءتها (مفاتيح التوقيع وقواعد البيانات وتخزين الملفات).
• اختبار مسارات رفع الصور في بيئة تجريبية للتأكد من عدم وجود اعتماد على عمليات غير آمنة.

إذا كنت تدير جهة تعتمد على الرفع الجماعي للصور—مثل منصات التجارة الإلكترونية أو الخدمات المالية الرقمية أو بوابات الهوية—فإن هذه الخطوات ليست مجرد “إصلاح ثغرة”، بل حماية لسلسلة كاملة من الحسابات والبيانات.

سؤال للنقاش

عندما تكون نقطة الدخول مجرد “ملف صورة”، هل لدى مؤسستك جرد دقيق لتبعيات معالجة الملفات وسياسة تدوير أسرار جاهزة فورًا—أم أن الإصلاح غالبًا ما يتوقف عند مجرد ترقية الإطار دون إعادة تقييم حدود الثقة داخل سلسلة المعالجة؟

Facebook |
X