rails-activestorage-vips-audit

مهارة وكيل تقوم بتدقيق مستودعات Ruby on Rails بحثًا عن التعرّض لـ CVE-2026-66066 (KindaRails2Shell) — ثغرة معالجة المتغيّرات في Active Storage libvips التي تسمح بقراءة ملفات عشوائية، وفي تطبيق Rails، بتنفيذ تعليمات برمجية عن بُعد.

المهارة هي أداة تدقيق إعدادات ومساعدة في المعالجة. لا تحتوي على أي تعليمات برمجية استغلالية ولا تصف سلسلة الهجوم.

الثغرة

CVE	CVE-2026-66066
الخطورة	حرجة، CVSS 9.5
الحزمة	activestorage (RubyGems)
المتأثرة	< 7.2.3.2، >= 8.0 < 8.0.5.1، >= 8.1 < 8.1.3.1
المُصحّحة	7.2.3.2، 8.0.5.1، 8.1.3.1
الإشعار	GHSA-xr9x-r78c-5hrm

يقرأ libvips الصيغ ويكتبها عبر عمليات، بعضها يوسمه بأنه unfuzzed — غير آمن للمحتوى غير الموثوق. لم تعطّلها Active Storage، لذا يمكن لمهاجم قادر على رفع ملف مصمّم خصيصًا الوصول إليها.

لا يكون التطبيق معرّضًا إلا عندما تتحقق الشروط الأربعة جميعًا:

1. activestorage ضمن نطاق إصدار متأثر
2. Active Storage قيد الاستخدام
3. config.active_storage.variant_processor يُحلّ إلى :vips
4. يقبل التطبيق عمليات رفع من مستخدمين غير موثوقين

الشرط 3 هو الشرط المُميّز. يشمل النطاق المتأثر < 7.2.3.2 كل إصدارات Rails 6.x، لكن 6.x يستخدم افتراضيًا :mini_magick، لذا لا يكون 6.x معرّضًا إلا في إعداد غير افتراضي، والإصدارات قبل 6.0 لا تحتوي على إعداد variant_processor على الإطلاق. يستخدم Rails 7.0 وما بعده :vips افتراضيًا عبر config.load_defaults 7.0، ولهذا السبب يكون الإعداد الشائع معرّضًا. يقبل Rails 8.1 أيضًا :disabled، مما يجعل الشرط 3 غير متحقق.

التثبيت

كإضافة Claude Code، عبر السوق المضمّن في هذا المستودع:

/plugin marketplace add paveg/rails-activestorage-vips-audit
/plugin install rails-activestorage-vips-audit@paveg-skills

باستخدام skills CLI، الذي يثبّت المهارة نفسها في Claude Code وCodex وCursor وCopilot CLI ووكلاء آخرين:

npx skills add paveg/rails-activestorage-vips-audit

أو يدويًا:

git clone https://github.com/paveg/rails-activestorage-vips-audit.git
cp -r rails-activestorage-vips-audit/skills/rails-activestorage-vips-audit ~/.claude/skills/

~/.agents/skills/ يعمل كموقع مشترك بين بيئات التشغيل Codex وCopilot CLI وGemini CLI. لا يعتمد أي شيء في المهارة على مكان تثبيتها — فلا توجد مسارات مطلقة، ويقوم collect-evidence.sh بحل كل شيء نسبةً إلى جذر التطبيق الذي يُشار إليه.

الاستخدام

للمهارة وضعان، وكلاهما يقبل مسارات تطبيقات متعددة.

report <app>...   # read-only audit, one verdict per application
fix <app>...      # applies remediation on a branch; never commits or pushes unprompted

عند التثبيت كإضافة، يكون كل وضع أيضًا أمرًا، لذا لا يلزم كتابة الوضع كوسيط:

/rails-activestorage-vips-audit:report path/to/app another/app
/rails-activestorage-vips-audit:fix path/to/app

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

report هو الافتراضي. يتطلب fix حكم report للتطبيق نفسه أولًا، لأن المعالجة الصحيحة تعتمد عليه — فـ Rails 6.x و7.0.x و7.1.x ليس لها تصحيح ضمن السلسلة نفسها، لذا يطبّق fix هناك التخفيف المؤقت ويُبلّغ بضرورة ترقية إطار العمل بدلًا من محاولة إجرائها.

يمكن أيضًا تشغيل جمع الأدلة بمفرده:

skills/rails-activestorage-vips-audit/scripts/collect-evidence.sh path/to/app another/app

يجمع السكربت الوقائع ولا يحتوي عمدًا على أي منطق لإصدار حكم. مرّر جذر تطبيق، لا جذر monorepo غير متمايز. في حالة monorepo، مرّر كل دليل Rails قابل للنشر يمتلك Gemfile.lock وconfig/application.rb خاصين به كوسيط منفصل. يستبعد الجامع جذور التطبيقات المتداخلة تلك من تدفق أدلة الأب، مع الاحتفاظ بجذور ملفات القفل المتداخلة التي قد تكون محركات مثبّتة أو تبعيات مسار.

ما لن يخبرك به

• إصدار libvips وقت التشغيل. لا يمكن معرفته بشكل قاطع من المستودع، وهو أمر مهم: في الإصدارات الأقدم من libvips 8.13 لا يمكن تعطيل العمليات غير الآمنة على الإطلاق. في تطبيق غير مُرقَّع يعني ذلك أن أي تخفيف لا يمكن أن ينجح؛ وفي تطبيق مُرقَّع يعني أن Active Storage يرفع استثناءً أثناء الإقلاع بدلًا من العمل غير آمن، لذا فإن ترقية غير مُتحقَّق منها تُفشل النشر بدلًا من ترك ثغرة صامتة. تحقّق باستخدام vips --version حيث يعمل التطبيق. تُبقي التقارير هذا ضمن جاهزية وقت التشغيل والمعالجة بدلًا من جعل حكم التعرّض مشروطًا به.
• ما إذا كان التخفيف فعّالًا. وجود VIPS_BLOCK_UNTRUSTED في Dockerfile لا يُثبت أن بيئة النشر تُعيّنه. تُحدّد المهارة هذه النتائج بحد أقصى "تخفيف مؤقت موجود، والترقية لا تزال مطلوبة" ولا تسمح أبدًا بأن يُنتج أحدها حكمًا نظيفًا.

ملخص المعالجة

قم بالترقية إلى 7.2.3.2 أو 8.0.5.1 أو 8.1.3.1، بما يطابق سلسلتك. تأكّد من libvips وقت التشغيل >= 8.13 وruby-vips >= 2.2.1 أولًا: حيث يكون ruby-vips مثبّتًا، يرفع Active Storage المُرقَّع استثناءً أثناء الإقلاع ما لم يتحقق الشرطان، وينطبق هذا الفحص على تطبيقات :mini_magick أيضًا.

التخفيفات المؤقتة، وليس أي منهما بديلًا عن الترقية:

• عيّن متغير البيئة VIPS_BLOCK_UNTRUSTED (libvips >= 8.13؛ لا حاجة لتغيير الـ gem)
• استدعِ Vips.block_untrusted(true) من initializer (ruby-vips >= 2.2.1، بالإضافة إلى libvips >= 8.13)

على ruby-vips < 2.2.1 يستدعي مسار الـ initializer دالة غير موجودة بعد، لذا ارفع إصدار الـ gem أولًا أو اتخذ مسار متغير البيئة، الذي لا يعتمد عليه.

إذا كان التطبيق قد تعرّض، فتعامل مع كل سر يمكن لعملية التطبيق قراءته على أنه مخترق وقم بتدويره: secret_key_base، والمفتاح الرئيسي، وبيانات اعتماد خدمة Active Storage، وبيانات اعتماد قاعدة البيانات، ورموز الأطراف الثالثة.

جدار الحماية WAF ليس تخفيفًا هنا. تعتمد قدرته على رؤية الحمولة على خدمة التخزين وطريقة الرفع، لذا فإن فعاليته تعتمد على الإعدادات أكثر من اللازم للاعتماد عليها.

إخلاء المسؤولية

• استخدم هذه المهارة فقط على المستودعات التي تملكها أو المصرّح لك صراحةً بتدقيقها.
• الأحكام هي تحليل ساكن بأفضل جهد ممكن. حكم NOT AFFECTED ليس دليلًا على عدم التعرّض: متغيرات بيئة النشر والكود في الخدمات الأخرى غير مرئية لتدقيق المستودع. يُبلَّغ عن libvips وقت التشغيل بشكل منفصل لأنه يؤثر على التخفيف وجاهزية النشر، لا على ما إذا كان المستودع يستوفي شروط التعرّض.
• لا تحتوي المهارة على أي كود استغلال ولن تعيد بناء سلسلة الهجوم، بغض النظر عن كيفية صياغة الطلب.
• تُقدَّم بموجب MIT License، دون أي ضمان من أي نوع. يبقى التصرف بناءً على تقرير — الترقيات، والتخفيفات، وتدوير الأسرار — مسؤولية المشغّل.

المصادر

• Rails security advisory GHSA-xr9x-r78c-5hrm
• Ethiack — KindaRails2Shell: Rails RCE (CVE-2026-66066)
• Rails guides — Configuring Rails Applications

اكتُشفت الثغرة وأُبلِغ عنها بشكل مستقل من قبل RyotaK من GMO Flatt Security وفريق من Ethiack مكوّن من André Baptista وBruno Mendes وCastilho، ثم أُفصح عنها بالتنسيق مع مشرفي Rails.