ثغرة في Rails Active Storage: افحص ثلاثة إعدادات قبل 7 نوفمبر

ثغرة بدرجة CVSS 9.8 في Rails Active Storage تتيح كتابة ملفات على خادمك عبر رفع صورة واحدة. افحص ثلاثة إعدادات وحدّث قبل انتهاء دعم Rails 8.0.

تقريبًا كل تطبيق Rails يقبل صورة شخصية أو مستندًا أو صورة منتج يمرّر ذلك الملف عبر Active Storage. في 4 نوفمبر 2026 نشر فريق Rails تنبيهًا أمنيًا حرجًا يخص مسار الرفع هذا. ففي بعض الإعدادات الشائعة، يمكن لملف واحد مُعَدّ بعناية أن يتيح لمهاجم غير مُصادَق كتابة ملفات على خادمك.

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

ما هي الثغرة

عند إرفاق ملف، يشغّل Active Storage محلّلًا لقراءة معلومات أساسية مثل أبعاد الصورة. ومع المعالج :mini_magick يسلّم هذا المحلّل الملف إلى ImageMagick. يدعم ImageMagick صيغًا كثيرة عبر وحدات تُسمّى coders، وبعضها قوي جدًا: إذ يُظهر commit الإصلاح ملف SVG مرفوعًا يصل إلى الـ coder المسمّى MSL، وهو صيغة برمجية نصية تستطيع قراءة الملفات المذكورة في نصها وكتابتها. لم يكن Active Storage يقيّد الـ coders التي يمكن أن يصل إليها الملف المرفوع، فكانت سياسة ImageMagick على الخادم هي خط الحماية الوحيد.

هناك تفصيلان يجعلان الأمر خطيرًا. أولًا، يعمل المحلّل عند الإرفاق، فلا حاجة إلى variant أو معاينة أو استدعاء صريح لـ analyze: يكفي قبول الملف المرفوع. ثانيًا، التطبيقات التي تخزّن الملفات بخدمة Disk يمكن أيضًا دفعها إلى قراءة أي ملف تستطيع عملية التطبيق قراءته. ويشمل ذلك secret_key_base وبيانات الاعتماد الخاصة بأنظمة أخرى، ما قد يؤدي إلى تنفيذ تعليمات برمجية عن بُعد أو إلى التحرك الجانبي داخل الشبكة.

أبلغ عن الثغرة RyotaK من GMO Flatt Security عبر HackerOne. ويشير فريق Rails إلى أنه أُبلغ عن سلسلة هجوم واحدة، وأنه لا يفترض أنها الوحيدة. ولا يذكر التنبيه ما إذا كانت الثغرة قد استُغلّت.

اختبار التعرّض بثلاثة شروط

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

الشرط	أين تبحث	تكون معرّضًا عندما
1. معالج الـ variants	config.active_storage.variant_processor وload_defaults	تكون قيمته :mini_magick (الافتراضية مع load_defaults 6.1 أو أقدم)
2. سياسة ImageMagick	الملف policy.xml على الخادم	لا تحظر MSL ولا coders الخاصة بـ Ghostscript ولا الـ delegate gs (السياسات الافتراضية في Debian وUbuntu لا تحظرها)
3. من يستطيع الرفع	نماذج الرفع وواجهات API لديك	يستطيع مستخدمون غير موثوقين إرفاق ملفات

1. أي معالج يستخدمه Active Storage؟

ابحث في إعداداتك واسأل التطبيق أثناء تشغيله:

grep -rn "variant_processor\|load_defaults" config/
bin/rails runner 'p Rails.application.config.active_storage.variant_processor'

منذ Rails 7.0 أصبحت القيمة الافتراضية :vips، لكن التطبيقات التي رُقّيت من إصدارات أقدم كثيرًا ما تظل تحمّل الإعدادات الافتراضية القديمة أو تضبط :mini_magick صراحةً. افحص أيضًا bundle info mini_magick: إذا كانت الـ gem ضمن الـ bundle لديك، فاعرف أين تُستخدم.

2. هل تحظر سياسة ImageMagick لديك الـ coders الخطرة؟

اعرض السياسة التي يحمّلها ImageMagick فعليًا على كل خادم تطبيق وكل worker:

magick -list policy      # ImageMagick 7
convert -list policy     # ImageMagick 6

ابحث عن قواعد تحتوي rights="none" للـ coder MSL، ولـ coders الخاصة بـ PostScript وPDF، وللـ delegate gs. إذا كنت تستخدم سياسة حزم Debian أو Ubuntu دون تعديل، فافترض أنها غير محظورة. وتذكّر أن صور الحاويات وخوادم الـ workers قد تشغّل نسخة من ImageMagick تختلف عن تلك الموجودة على خوادم الويب.

3. هل يستطيع مستخدمون غير موثوقين رفع الملفات؟

حدّد كل موضع يصل فيه ملف إلى attach أو has_one_attached أو has_many_attached، بما في ذلك واجهات API والرفع المباشر وأدوات الإدارة التي تستورد ملفات من الخارج. والتسجيل العام الذي يتضمن حقلًا للصورة الرمزية يُعدّ مصدرًا غير موثوق.

الإصلاح: مسارات التحديث لكل فرع

الإصداران المُصلَحان هما Rails 8.1.4.1 وRails 8.0.5.2. ويعالجان معًا 21 مشكلة أمنية، لذا يستحقان التثبيت حتى لو لم تكن معرّضًا لهذه الثغرة.

الفرع لديك	ما يجب فعله
8.1	التحديث إلى 8.1.4.1
8.0	التحديث إلى 8.0.5.2 الآن، ثم التخطيط للانتقال إلى 8.1: ينتهي الدعم الأمني لـ 8.0 في 7 نوفمبر 2026
7.2 وما قبله	لن يصدر أي إصلاح. طبّق الحل البديل الخاص بالسياسة أدناه وحدّث إلى 8.0 أو أحدث

تحتاج التطبيقات التي تستخدم :mini_magick أيضًا إلى mini_magick 5.1 أو أحدث. فمع إصدار أقدم يُطلق الإصدار المُصلَح خطأً عند الإقلاع، لذا حدّث الـ gems معًا واختبر الإقلاع في بيئة staging:

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

تأتي الإصدارات المُصلَحة بسياسة ImageMagick خاصة بها، لكن تحقّق من أنها تصل فعلًا إلى ImageMagick. فهي لا تُطبَّق إذا كان تطبيقك يستبدل MiniMagick.cli_env بعد الإقلاع، أو يستخدم MiniMagick.cli_prefix، أو يثبّت MiniMagick::Shell خاصًا به؛ وتحتاج هذه التطبيقات إلى القواعد في سياسة النظام. أما GraphicsMagick فلا يقرأ سياسات ImageMagick إطلاقًا. كما أن السياسة المرفقة تُضاف إلى policy.xml على خادمك بدلًا من أن تحل محله، لذا فإن أي قاعدة سماح هناك، بما فيها الـ wildcard، تتغلب على الحظر.

تُصلح الإصدارات نفسها ثغرة ثانية هي GHSA-v924-7rp8-4mxh (CVSS 8.8). كان Active Storage يمرّر الملفات المرفوعة إلى ImageMagick وFFmpeg بأسماء مؤقتة تحتفظ بامتداد الملف الأصلي، فكان بإمكان مهاجم يتحكم في اسم الملف ونوع المحتوى المُعلَن أن يؤثر في أي decoder يعمل. والحلول البديلة التي يقدمها Rails لهذه الثغرة تغطي FFmpeg فقط، وهذا سبب إضافي للتحديث بدلًا من الاعتماد على الحلول البديلة.

نمط متكرر لا حادثة منفردة

في يوليو 2026 كانت CVE-2026-66066 ثغرة حرجة منفصلة في Active Storage أثّرت في التطبيقات التي تستخدم libvips. لم تكن التطبيقات المعتمدة على ImageMagick معرّضة لذلك المسار، لكنها معرّضة لهذا المسار. ثغرتان حرجتان خلال أربعة أشهر، عبر مكتبتَي الصور المدعومتين كلتيهما، تشيران إلى الدرس نفسه: معالجة الصور سطح هجوم واسع، وActive Storage يشغّلها على ملفات من غرباء لحظة إرفاقها.

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

إذا لم تتمكن من التحديث فورًا

نشر Rails أيضًا commits التصحيح للفرعين 8.1 و8.0. وإلى أن تتمكن من نشر إصدار مُصلَح، اتبع قائمة التحقق هذه:

1. أضف القواعد الدنيا الواردة في التنبيه إلى سياسة نظام ImageMagick على كل خادم يعالج الملفات المرفوعة (مثل /etc/ImageMagick-7/policy.xml).
2. تأكد من عدم وجود قاعدة سماح أو wildcard في الملف نفسه تتغلب عليها، ثم تحقّق باستخدام magick -list policy.
3. إذا كنت تعرض ملفات PDF أو PostScript عبر ImageMagick، فأعد السماح بالـ delegate gs وبالـ coders التي تحتاجها فقط، وتقبّل أن ذلك يُبقي قدرًا من المخاطرة.
4. قيّد عمليات الرفع: احصر مؤقتًا من يستطيع إرفاق الملفات، أو أوقف الرفع المجهول الهوية.
5. إذا كنت تستخدم خدمة Disk، فخطّط لتدوير secret_key_base والمفتاح الرئيسي (master key) ومحتويات config/credentials.yml.enc وبيانات اعتماد التخزين وقاعدة البيانات ورموز الأطراف الثالثة. ولا تُبقِ أي سرّ مكشوف كخيار احتياطي.

القواعد الدنيا المنشورة في التنبيه هي:

<policy domain="coder" rights="none" pattern="MSL"/>
<policy domain="delegate" rights="none" pattern="gs"/>
<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}"/>

اقرأ التفاصيل الكاملة في التنبيه الأمني من Rails.

كيف يمكن لـ LOGIQ أن تساعد

تدعم LOGIQ الفرق التي تشغّل حزمًا مفتوحة المصدر على Linux، من صورة نظام التشغيل إلى بيئة تشغيل التطبيق. إذا أردت مساعدة في فحص سياسات ImageMagick عبر خوادمك، أو في التخطيط للانتقال من فرع يقترب دعمه من الانتهاء، تحدّث إلى فريقنا.