تثبيت SHA ليس تحققًا: Plugin4Shell وأول ثغرة RCE في سلسلة توريد وكلاء الذكاء الاصطناعي

لقد اختُطفت 925 مهارة إضافية (skills) بالفعل من صاحبيها الأصليين، وتصل تلك المهارات إلى 134,000 وكيل. في 17 سبتمبر 2026 كشفت AIR Security عن Plugin4Shell — أول ثغرة في سلسلة التوريد ضمن منظومة وكلاء الذكاء الاصطناعي: تنفيذ عن بُعد للكود بدون نقرة (RCE) يمس Claude Code وOpenAI Codex وGitHub Copilot وGoogle Gemini CLI، جميعها عبر نفس الفحص المفقود. الآلية هي تأكيد git واحد يتجاوزه كل وكيل متأثر: يفحص الوكيل SHA الـcommit المثبّت من الـmarketplace لكنه لا يتحقق أبدًا من أن شجرة العمل هبطت فعلًا على ذلك الـcommit. المهاجم الذي يسيطر على مستودع إضافة (plugin) يسمّي فرعًا باسم SHA المثبّت المكوّن من 40 محرفًا، ويجعله الفرع الافتراضي للمستودع، فيثبّت الوكيل كودًا يسيطر عليه المهاجم بينما يبلّغ عن تثبيت نظيف عند الـcommit المثبّت (Cyber Security News؛ Help Net Security).

هذا يهم أي فريق يشغّل وكلاء برمجة في مواجهة أنظمة إنتاج لأن التثبيت (pin) كان هو الضابط. المنظمات التي تتجاوز marketplace مجتمعية — بمراجعة كود الإضافات وتثبيت التثبيبات على commit مُراجَع — اعتمدت على تثبيت SHA كحماية لها، وPlugin4Shell يُبطلها بصمت: المراجعة تنجح، والـpin يُكتب، ويُشغَّل كود مختلف (AIR). يغطي هذا المقال أربع نقاط يحتاجها مدير الهندسة قبل أن تُطلق التحديثة التلقائية التالية لإضافة ما: الآلية في أمر git واحد، والهجوم ذو الخطوات الخمس من التبني الحميد إلى RCE في الخلفية، ولوحة استجابة المزودين (اثنان مُصلحان، وواحد غير مُصلح، وواحد مهجور غير مُصلح)، وبنود التحقق التي تغلق الفجوة لكل أداة مثبّتة يثبّتها وكلاؤك — إضافات وخوادم MCP ومهارات.

الاستنتاجات الرئيسية

• ثغرة RCE بدون نقرة أصابت الوكلاء البرمجيين الأربعة الكبار — Claude Code وCodex وGitHub Copilot وGemini CLI — عبر تأكيد git واحد مفقود — كشفت AIR عن Plugin4Shell في 17 سبتمبر 2026: يفحص الوكلاء SHA الـcommit المثبّت من الـmarketplace لكنهم لا يتحققون من أن الـcheckout حُلّ إليه (AIR).
• 925 مهارة اختُطفت بالفعل من صاحبيها لتصل إلى 134,000 وكيل — بحث SkillJacking من AIR؛ Plugin4Shell يحطّم آلية تثبيت SHA المبنية خصيصًا لاحتواء هذا النوع من الاستحواذ على المستودعات (AIR).
• Git يفضّل الفرع الذي يحمل اسمًا يشبه الهاش على الهاش نفسه — فرع يحمل SHA المثبّت المكوّن من 40 محرفًا اسمًا له، وقد صار الفرع الافتراضي للمستودع، يعيد توجيه git checkout <sha> إلى كود المهاجم؛ بينما يحجب متغير Gemini CLI الـFETCH_HEAD بدلًا من ذلك (Cyber Security News).
• لوحة استجابة المزودين: 2 مُصلحان، و1 غير مُصلح، و1 مهجور غير مُصلح — رقّعت Anthropic Claude Code في 2.1.179 ورقّعت OpenAI Codex في 0.146.0؛ ولم تُصدر Microsoft أي إصلاح لـCopilot، وأهملت Google Gemini CLI دون ترقيع، ما يعني بقاء كل تثبيت قائم معرضًا للخطر (Help Net Security).
• تأكيد واحد يغلق المتغيّرين معًا: تحقق من الـHEAD المُحلَّل مقابل الـSHA المثبّت بعد الـcheckout — test "$(git rev-parse HEAD)" = "<pinned-sha>" || abort — ويجب أن يعمل التحقق داخل الوكيل، لأن لا marketplace يمكنها فرض تثبيت لا تحلّه بنفسها (AIR).

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

الآلية: تأكيد واحد، أربعة وكلاء

تثبيت SHA هو نموذج أمان الـmarketplace وهو يعمل كما صُمم. يفحص مراجع إضافة عند commit معين، ويسجّل الـmarketplace SHA ذلك الـcommit، ويفترض أن الوكيل يثبّت ذلك الكود نفسه إلى الأبد. الفشل في الخطوة الأخيرة. كل وكيل متأثر يشغّل تقريبًا هذا التسلسل (AIR):

git clone  ./
git checkout aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   # SHA المثبّت

ولا يسأل أبدًا إن كان الـcheckout قد هبط فعلًا على الـcommit المثبّت. هذه الفجوة قابلة للاستغلال لأن git يحلّ الأسماء قبل الكائنات: عندما يكون الاسم في آنٍ واحد ref صالحًا وهاش commit، يفضّل git الـref ويطبع تحذير refname is ambiguous فقط. المهاجم — الذي يسيطر أصلًا على المستودع الأصلي — ينشئ فرعًا اسمه هو بالضبط SHA المثبّت المكوّن من 40 محرفًا سداسيًا، ويجعله الفرع الافتراضي للمستودع. عملية git clone عادية تجلب ذلك الفرع كـref محلي، ويحلّ git checkout <sha> إلى الفرع، فتصبح شجرة العمل تحت سيطرة المهاجم بينما يبلّغ الوكيل عن تثبيت ناجح عند الـSHA المثبّت (Cyber Security News).

شرطان يجعلان الحيلة ناجحة. الأول: لا شيء يمنع عالميًا فرعًا اسمه يشبه الهاش؛ فالأداة check-ref-format في git نفسها تقبل أسماء سداسية من 40 محرفًا، وبينما يرفضها GitHub رفضًا قاطعًا، تسمح بها Bitbucket وخوادم git المستضافة ذاتيًا — ووثائق Anthropic ذاتها تذكر Bitbucket وgit المستضاف ذاتيًا كخلفيات marketplace صالحة (AIR). الثاني: يجب أن يكون الفرع هو الافتراضي للمستودع؛ الفرع غير الافتراضي يصل فقط كـref للتتبع البعيد، فيعود الـcheckout إلى الـcommit الحقيقي.

يفشل Gemini CLI بطريقة مختلفة. تسلسل تثبيته يجلب الـcommit المثبّت ثم يفحص FETCH_HEAD:

git clone --depth 1  ./
git fetch origin 41d0bc0a4aeb2fbf797dacea39e876d98c95024b
git checkout FETCH_HEAD

إذا كان الفرع الافتراضي للمستودع يحمل هو نفسه اسم FETCH_HEAD، يحلّ الـcheckout إلى ذلك الفرع ويتجاهل بصمت الـcommit الذي جُلب (AIR). أمر مختلف، والسبب الجذري نفسه: يثق الوكيل بالاسم الذي طلبه بدل التحقق من الـcommit الذي استلمه.

الهجوم من البداية إلى النهاية: خمس خطوات من التبني إلى RCE

لا يتطلب أيٌّ من مساري الهجوم السيطرة على الـmarketplace. أوضحت AIR المسارين:

1. الزرع. ينشر المهاجم إضافة حميدة حقًا، مثبتة على commit aaa…aaa، فتجتاز المراجعة.
2. التبني. يثبّتها المستخدمون، فتُثبَّت كل عملية على الـcommit المراجَع.
3. إعادة التثبيت. يدفع المهاجم تحديثًا روتينيًا ما يزال حميدًا؛ فيرفع الـmarketplace الـpin إلى bbb…bbb.
4. السحب (Rug-pull). ينشئ المهاجم فرعًا باسم bbb…bbb، ويجعله الفرع الافتراضي، ويوجهه إلى كود خبيث. يمكن أن يبقى الـcommit المثبّت سليمًا.
5. التحديث التلقائي إلى RCE. يحفّز الـpin المتغيّر التحديث التلقائي في الخلفية لكل الوكلاء — السلوك الافتراضي في Claude Code وCodex — فيحلّ الـcheckout الـpin الجديد إلى الفرع، ويُشغَّل الكود بلا نقرة ولا تنبيه ولا إعادة تثبيت (AIR).

المسار البديل أسرع: الاستحواذ على مستودع صاحب إضافة مشروع والاستغناء عن خطوة الزرع كليًا. ويقدّر بحث AIR المكمّل كم أصبح هذا شائعًا — 925 مهارة اختُطفت من صاحبيها الأصليين لتصل إلى 134,000 وكيل (AIR). إنها الفصل الثالث في سلسلة: أظهرت The Story of Skills مهارة خبيثة تصل إلى 26,000 وكيل، وعثر MCPJacking على 155 خادم MCP قابلة للاختطاف في الـmarketplace الرسمي عبر نطاقات منتهية، سجّلها الباحثون ليحصلوا على تنفيذ عن بُعد للـprompts في كل وكيل يثق بها (AIR). وPlugin4Shell هو فشل الحدود في الآلية التي بناها القطاع لاحتواء كل ذلك. ومدى الانفجار أوسع من الوكيل نفسه: الإضافات والـadd-ons ترث صلاحيات المطور الذي يشغّل الوكيل — الشيفرة المصدرية المحلية، وبيانات اعتماد السحابة، ومفاتيح SSH، والمستودعات الداخلية، وأنظمة الإنتاج (Cyber Security News).

لوحة استجابة المزودين: اثنان مُصلحان، وواحد غير مُصلح، وواحد مهجور غير مُصلح

يبيّن الجدول الزمني للإفصاح أن الإفصاح المنسّق نجح — وأين توقف:

متى	ماذا
مايو 2026	تعثرت AIR بالثغرة، مع PoC عاملة ضد الوكلاء الأربعة
يونيو 2026	إفصاح منسّق للمزودين الأربعة
17 يونيو 2026	أكدت Anthropic الإصلاح في Claude Code 2.1.179
4 أغسطس 2026	أكدت Google أن إصلاحًا لن يصدر — Gemini CLI مهجورة؛ يُطلب من المستخدمين الانتقال إلى Antigravity
12 أغسطس 2026	أكد إصلاح Codex 0.146.0 لدى OpenAI
17 سبتمبر 2026	الإفصاح العلني

وحتى 18–19 سبتمبر، اللوحة لم تتغيّر: Anthropic رقّعت، وOpenAI رقّعت، ولم تُصدر Microsoft إصلاحًا لـCopilot، وأهملت Google Gemini CLI دون ترقيع — ما يعني بقاء كل تثبيت قائم من Gemini CLI معرضًا للخطر إلى أجل غير مسمى (Help Net Security). رد GitHub — بحظر أسماء الفروع والوسوم ذات الشكل الـSHA على منصتها — لا يغلق الفجوة، لأن الـmarketplaces يمكن استضافتها على Bitbucket أو خوادم git مستضافة ذاتيًا حيث تبقى تلك الأسماء مشروعة (Cyber Security News).

خلاصة AIR هي الأصدق: "The fix has to ship in the agent, and updating is the only complete mitigation where one exists" (AIR). والسبب البنيوي يستحق أن يُعاد ذكره في محادثات الشراء: الـpin يُحلّ داخل الوكيل، فلا يستطيع أي marketplace فرض الضمانة التي يدّعيها. الفحص من جانب المزود لعمليات الرفع إلى الـmarketplace (أطلقت Anthropic ميزة Skill/Plugin Scanning في 6 أغسطس 2026) يقلل احتمال دخول إضافة خبيثة إلى الـmarketplace، لكنه لا يعوض التحقق من الـcheckout داخل الوكيل — فالاستبدال يقع بعد المراجعة، وعند لحظة الحل (MCP Security Hardening Checklist). وهذا أيضًا هو المثال الحاكم: أربعة مزودين، وعيب تصميم مشترك، واستجابة غير متكافئة تدور يومها الثالث — يمكن لمنظمة مشترية قراءتها كنموذج مصغّر لوتيرة الترقيع الأمني لدى المزود.

التحقق بعد الـcheckout: الضابط القابل للتعميم

سطر AIR الواحد يغلق المتغيّرين معًا (AIR):

test "$(git rev-parse HEAD)" = "" || abort

والتفاصيل تحمل الدرس. يحلّ git rev-parse HEAD ما تحتويه شجرة العمل فعلًا — لا الاسم الذي طُلب. وهذا التمييز تحديدًا هو ما تسلل منه متغيّر FETCH_HEAD لدى Gemini. ويجب أن يعمل التحقق داخل الوكيل، لأن الـpin يُحلّ على العميل. الـmarketplace التي تتحقق بعد الـcheckout لا تتحقق إلا من سجلها الخاص؛ والوكيل هو المكوّن الذي يجب أن يتوقف عند عدم التطابق.

هذا النمط — التحقق بعد الحل لا قبله — يُعمَّم على كل ضابط لأداة مثبّتة في منظومة الوكلاء. إصدار خادم MCP مثبّت، ومهارة مثبّتة، وأوزان نموذج مثبّتة، وdigest حاوية مثبّت: كلٌّ منها ادعاء يُتوقع من مُثبِّت ما الوفاء به ولا يتحقق أحد من نتيجة حله. نفس التأكيد المفقود موجود أينما وقع الـcheckout. أربعة بنود للعمل عليها هذا الأسبوع:

1. حدّث الوكلاء الذين صدر لهم إصلاح. Claude Code إلى 2.1.179 أو أحدث؛ وCodex إلى 0.146.0 أو أحدث. لا إصلاح لـCopilot ولا لـGemini CLI — قيّد ما يمكن لهذين الوكيلين الوصول إليه (نظام الملفات، وبيانات الاعتماد، والشبكة الصادرة) حتى يصدر إصلاح، أو اتبع مسار الترحيل الذي حدده المزود.
2. افحص مخزون كل أداة مثبّتة. إضافات، ومهارات، وإصدارات خوادم MCP، ومثبِّتات داخلية. لكل منها، تأكد إن كانت هناك مسار كود يتجاوز تأكيد الـHEAD المُحلَّل — ويشمل ذلك أدوات داخلية كتبها فريقك، لا الوكلاء المزودين فقط.
3. دقّق مستودعات الإضافات بحثًا عن إشارات استحواذ. تغيّرات فروع غير متوقعة، ونقل للفرع الافتراضي، وانتقال ملكية. اختُطفت المهارات الـ925 قبل هذا الإفصاح؛ والاستحواذ على المستودعات هو خطوة الدخول وهي تعمل بالفعل على نطاق واسع (Cyber Security News).
4. عامِل التحديث التلقائي للإضافات كقناة تسليم في سلسلة التوريد لا كوسيلة راحة. ضع الـmarketplaces والمستودعات المسموح للوكلاء السحب منها في قائمة سماح، وجعل إعادة التثبيت خضع لإعادة مراجعة حيث تسمح إعدادات الوكيل. صفة «بدون نقرة» مصدرها التحديث التلقائي — أزل «بدون» وسيلزم الهجوم مجددًا فعلًا من المستخدم.

ثغرتا CVE مجاورتان، والانكشاف الممتد

أنتجت الأسبوع نفسه ثغرتَي CVE في خوادم MCP تشارك Plugin4Shell موضوعه — ثقة وُضعت في مكوّن لم يتحقق قط من مستدعيه. تؤثر CVE-2026-54618 في Obsidian Web MCP قبل 0.2.0: كان endpoint تفويض OAuth يُصدر رموزًا لأي مستدعٍ دون مصادقة المستخدم، ما منح مهاجمًا بعيدًا غير مُصادق وصولًا كاملًا للقراءة والكتابة والبحث والنقل والحذف على الـvault بأكمله، وأُصلح في 0.2.0 (Rapid7؛ إرشاد GitHub GHSA-hwhg-mrjc-8g43). وتُعد CVE-2026-54446 عيب مصادقة مفقودة (CWE-306) في NetLicensing-MCP (Practical DevSecOps). وترتكز الثغرتان على أرقام مرجعية للنظام البيئي لم تتحرك منذ شهور: أكثر من 97 مليون تنزيل شهري لـMCP، و82% من الخوادم المفحوصة ضعيفة أمام path traversal، و8.5% فقط تستخدم OAuth (Practical DevSecOps).

والنمط عبر الإفصاحات الثلاثة واحد في كل طبقة من منظومة الوكيل: آلية ثقة — تثبيت، أو تدفق OAuth، أو endpoint لخادم — تنفّذ فحصها في اللحظة الخاطئة أو لا تنفّذه أصلًا. وPlugin4Shell هو ببساطة الأول الذي عبر من منتج واحد إلى المنظومة كلها دفعة واحدة.

قراءات ذات صلة

• MCP Security Hardening Checklist: 1,467 Exposed Servers and the Controls That Close Them — خط الأساس المكوّن من 12 ضابطًا الذي تندرج فيه هذه الثغرة: ينتمي Plugin4Shell إلى طبقة سلسلة التوريد (الضوابط 5–7)، بجوار تحديث Skill/Plugin Scanning
• Shadow AI Agents: 17,800 Add-Ons, 6.7 Million Installations, and the Runtime Control Gap — المخزون وفجوة الضوابط في وقت التشغيل اللذان يحدّان إن كان ستُلاحظ إضافة مختطفة
• The First MCP CVE on the KEV List Hit Its Federal Deadline: LiteLLM and the Default-Key Vault — ثغرة MCP CVE التي بلغت حدّ المعالجة الفيدرالية، وبنود التحقق الستة للـgateway التي تغلقها

---

تشغّل شركة توزيع صناعي متوسطة الحجم Claude Code لأدواتها الداخلية، ووكيل مشتريات يقدّم عروض الأسعار في مواجهة NetSuite وكاتالوجَي موردين. جرد الفريق كل أداة مثبتة على السطحين، وترقّى Claude Code إلى 2.1.179، وعطّل التحديث التلقائي للإضافات في الخلفية، وأضاف تأكيد الـHEAD المُحلَّل إلى مُثبِّت وحدات MCP الداخلي. انتقلت مصادر الإضافات إلى قائمة سماح لمستودعَين مُراجَعَين، ويسجّل مسار التدقيق كل إعادة تثبيت مع الـdiff الخاص بها. يصبح حادث الـmarketplace التالي مجرد ترقية إصدار ومراجعة، لا استجابةً لحوادث.

اطلب بناءً بمجال محدد. أسبوع discovery واحد. تحصل على جرد للأنظمة وخريطة لسير العمل ونطاق ثابت — سواء بنيتم معنا أم لا.