Plugin4Shell: أربعة وكلاء برمجة بالذكاء الاصطناعي وثقوا برمز PIN لم يتحققوا منه قط

في 17 سبتمبر 2026، نشرت AIR Security، وهي شركة ناشئة تبني أدوات أمنية لوكلاء الذكاء الاصطناعي المؤسسي، بحثًا يصف Plugin4Shell — ثغرة تنفيذ تعليمات برمجية عن بُعد من دون نقر في أربعة وكلاء برمجة بالذكاء الاصطناعي: Claude Code من Anthropic، وCodex من OpenAI، وGitHub Copilot، وGemini CLI من Google. لا تكمن الثغرة في أي نموذج. بل تكمن في عملية git checkout التي يجريها كل وكيل عند تثبيت إضافة، وفي أن أيًا من الأربعة لم يتحقق من أن الشيفرة التي تلقاها هي الشيفرة التي كان قد ثبّتها. وكان اثنان من الأربعة قد حصلا على تصحيح بحلول وقت نشر البحث علنًا. أما الاثنان الآخران فلم يحصلا عليه. هذا الحادث مدخل واحد في Orca AI Incident Archive، حيث يسجّله بوصفه ثغرة عالية الخطورة في سلسلة التوريد لم يُبلَّغ عن أي استغلال لها.

ما الذي أخطأ فيه الوكلاء في الواقع

كل وكيل متأثر يثبّت إضافات من سوق، وكل سوق يثبّت إضافة على التزام git محدد — بصمة SHA من 40 حرفًا — بمجرد مراجعة الإضافة. هذا التثبيت هو نموذج الأمان بأكمله: يوافق مُراجع على نسخة واحدة غير قابلة للتغيير، ويُفترض أن يظل الوكيل يعمل بتلك النسخة حتى لو تغيّر المستودع الذي يقف خلفها لاحقًا. يصف AIR هذا الخلل بأنه تجاوز لتثبيت SHA الخاص بالإضافة. يستخرج الوكيل الالتزام المحدد الذي ثبّته السوق بدقة لكنه لا يتحقق أبدًا من أن شجرة العمل التي ينتهي إليها هي ذلك الالتزام. وبكلمات الباحثين، فإن الوكيل "يستخرج الالتزام المحدد الذي ثبّته السوق بدقة لكنه لا يتحقق أبدًا من أنه استقر هناك، لذا فإن مهاجمًا يتحكم في مستودع الإضافة يجعل عملية الاستخراج تُحلّ إلى شيفرة خبيثة بينما يظل التثبيت يبدو محترمًا."

Git يسدّ هذه الفجوة. عندما يكون الاسم صالحًا كفرع وككائن commit في آن واحد، يفضّل git الفرع ولا يطبع سوى تحذير بالغموض. أما المهاجم الذي يتحكم في مستودع الإضافة فينشئ فرعًا اسمه مطابق تمامًا لـ SHA المثبّت المكوّن من 40 خانة سداسية عشرية، ويوجّهه إلى شيفرة خبيثة، ويجعله الفرع الافتراضي للمستودع. عندئذٍ يجلب clone عادي ذلك الفرع محليًا تحت الاسم الشبيه بـ SHA، ثم يُحلّ checkout اللاحق إليه. ويمكن أن يبقى الـ commit المثبّت نفسه دون مساس، فلا يبدو أي شيء في النسخة المراجَعة خطأً. وفقًا لـ AIR، يجب أن يتحقق شرطان: أن يكون الفرع المسمّى بـ SHA هو الفرع الافتراضي، لأن الفرع غير الافتراضي لا يُجلب إلا كمرجع تتبّع بعيد وسيرتد الـ checkout إلى الـ commit الحقيقي؛ وأن يقبل مضيف git اسم فرع مكوّنًا من 40 خانة سداسية عشرية. يرفض GitHub تلك الأسماء رفضًا قاطعًا. أما Bitbucket وخوادم git المستضافة ذاتيًا فلا ترفضها.

فشل Gemini CLI عبر مسار مختلف. فقد جلب الـcommit المثبّت، وسجّله في ملف FETCH_HEAD الخاص بالمستودع، ثم نفّذ عملية checkout لـFETCH_HEAD — وهي عملية checkout لا يلزمها قراءة ذلك الملف. وأي مستودع يكون فرعه الافتراضي نفسه باسم FETCH_HEAD يعيد توجيه عملية checkout إلى محتوى يتحكم به المهاجم، ويتجاهل بصمت الـcommit الذي جُلب. وتتطابق رواية Cybersecurity News لهذه الآلية مع رواية AIR، بما في ذلك التمييز بين المتغيّرين.

لماذا لم يضطر أحد إلى النقر على أي شيء

تُعاد عملية السحب نفسها للتنفيذ أثناء التحديث التلقائي للإضافة في الخلفية، وهو السلوك الافتراضي في Claude Code وCodex. وهذا ما يجعل الهجوم بنقرة صفرية بدلًا من كونه مجرد هجوم صامت: فعندما يرفع سوق ما قيمة SHA مثبتة إلى إصدار جديد روتيني، يعيد كل وكيل لديه الإضافة مثبتة بالفعل تنفيذ عملية السحب دون أي مطالبة ودون أي إجراء من المستخدم. مغزى AIR هو أن الضحية لا يلزمها أن تثبّت أي شيء بإهمال. كل ما يلزمها هو أن تكون قد ثبّتت إضافة واحدة، من سوق تثق به، جرى مراجعتها وتثبيتها تمامًا كما يقصد التصميم.

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

الأرقام الكامنة وراء هذين المسارين تأتي من عمل AIR السابق، لا من Plugin4Shell. وفي حملة تسميها الشركة The Story of Skills، تقول إن إضافة بنتها انتشرت إلى أكثر من 26,000 وكيل قبل سحبها. وفي SkillJacking، أفادت بأن 925 مهارة كانت قيد الاستخدام الفعلي قد استُولي عليها من القائمين على صيانتها الأصليين، لتصل إلى 134,000 وكيل. ويقول عنوان AIR لمنشور Plugin4Shell إن «ملايين الوكلاء متأثرون»؛ لكن البحث لا يقدم عددًا للتنصيبات المكشوفة، ولم ينشر أي طرف ثالث عددًا كذلك.

الجدول الزمني، وأين جرى تطبيق الإصلاحات

تقول AIR إنها اكتشفت الثغرة في مايو 2026 باستخدام أدوات استغلال إثبات مفهوم عاملة ضد الوكلاء الأربعة جميعًا، وأفصحت عنها لكل بائع في الشهر التالي ضمن الإفصاح المنسّق. وأكّدت Anthropic إصلاحها في Claude Code 2.1.179 في 17 يونيو. وأبلغت Google شركة AIR في 4 أغسطس بأنه لن يُطرح أي إصلاح، لأن Gemini CLI سيُتقاعد. وتم التحقق من إصلاح Codex 0.146.0 في 12 أغسطس. ولم تُصدر Microsoft إصلاحًا لـ GitHub Copilot.

إصدارات التصحيح هي التأكيد العلني الوحيد على أن العيب كان حقيقياً في المنتجين اللذين أصلحاه. تسرد مدخلات سجل التغييرات المنشورة من Anthropic للإصدار 2.1.179 معالجة انقطاع الاتصال، والتمرير في WSL2، وإصلاحات glob وواجهة صندوق العزل، ولا تذكر تثبيت الإصدارات أو التحقق من الإضافات أو أي إصلاح أمني من أي نوع. وقد أورد The Hacker News الملاحظة نفسها، وفقاً لرواية The Next Web. واعتباراً من نشر البحث، لم يكن قد تم تعيين أي معرف CVE، وتكرر المذكرة البحثية الصادرة عن Cloud Security Alliance حول العيب أنه لم يكن هناك أي معرف بعد ثلاثة أشهر من إخطار البائعين.

أربعة موردين، ثلاث إجابات مختلفة

ذهبت Google أبعد من مجرد رفض إصدار تصحيح. فقد أوقفت Gemini CLI، مما يعني أن التثبيتات الحالية تظل عرضة للخطر طالما استمر الناس في تشغيلها. ونصيحتها هي الانتقال إلى Antigravity، بيئة التطوير الوكيلية الأحدث، التي تقول AIR إن الهجوم لا يصل إليها لأنها لا تتضمن تثبيت SHA لإضافات السوق يمكن تجاوزه.

موقف GitHub مختلف مرة أخرى. صرّح متحدث باسم GitHub لـ The Register بأن المنصة لا تسمح للمستخدمين بإنشاء أسماء فروع أو وسوم تشبه معرّفات commit SHA، وأن «هذا التخفيف يضمن عدم إمكانية استغلال الثغرة الأمنية المُبلّغ عنها على GitHub». وتعترض AIR على نطاق ذلك التخفيف لا على وجوده: فقد قال الباحثون لـ The Register إنه يمكن استضافة الأسواق على منصات أخرى مثل Bitbucket، ولا يزال GitHub Copilot يدعم الأسواق من تلك المنصات، لذا يظل البديل المتعلق باسم الفرع قابلاً للوصول لمستخدمي Copilot. وتقول AIR أيضًا إن وثائق Anthropic الخاصة بها تسرد Bitbucket وgit المستضاف ذاتيًا كخلفيات صالحة للأسواق؛ فيما تصف وثائق Anthropic الحالية للأسواق إضافة سوق من عنوان URL لمستودع git، وليس من GitHub فقط. ولم ترد Microsoft على طلب The Register للتعليق، وقالت AIR إنها لم تتلقَّ أي رد من Microsoft منذ الإبلاغ عن المشكلة في يونيو، مشيرة إلى حجم الإفصاحات التي تتعامل معها الشركة.

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

ما هو ثابت، وما هو غير ثابت

• مُثبت: الآلية. يقدّم تقرير AIR أوامر git الدقيقة، وقاعدة الحسم التي تُرجّح المرجع على الكائن، والشرطين اللذين تحتاجهما حيلة الفرع، والمتغيّر المنفصل FETCH_HEAD الخاص بـ Gemini CLI. وقد نقلت ذلك The Register وHelp Net Security وCybersecurity News وInfoWorld وThe Next Web جميعها بالطريقة نفسها.

• المُثبت: إصداران مُرقّعان. أكّدت Anthropic أن Claude Code 2.1.179 في 17 يونيو 2026، وتم التحقق من إصلاح Codex 0.146.0 التابع لـ OpenAI في 12 أغسطس 2026، وفقًا للجدول الزمني للإفصاح الخاص بـ AIR.

• مؤكد: منتجان لم يكن لهما تصحيح عند الإفصاح. لن تقوم Google بتصحيح Gemini CLI وستوقف دعمه؛ ولم تُطلق Microsoft إصلاحًا لـ Copilot.

• غير مُثبت: إعادة إنتاج مستقلة. تعود كل الروايات المنشورة إلى تدوينة AIR الخاصة، كما أن مذكرة بحث Cloud Security Alliance لا تصف صراحةً أي تحقق تقني من طرف ثالث أو إعادة إنتاج مستقلة للثغرة. ولهذا السبب يُصنّف الأرشيف ثقة هذا السجل بدرجة B.

• غير مثبت: عدد المنشآت التي تعرضت فعليًا للكشف غير معروف. "الملايين" هو توصيف AIR في عنوانها، وليس رقمًا مقيسًا.

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

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

ثمة فحص واحد من طرف ثالث يضيّق الصورة العملية. وتذكر The Next Web، في تلخيصها لفحوصات أجرتها The Hacker News، أن الإضافات في كتالوج Anthropic المجتمعي وفي كتالوجات Claude Code وCopilot الافتراضية تشير إلى مستودعات GitHub، وأن التحديث التلقائي مفعّل افتراضيًا بشكل أساسي لتلك الأسواق المدمجة. ولأن GitHub يرفض أسماء الفروع التي تأخذ شكل SHA، فإن متغيّر اسم الفرع يكون أصعب في الوصول إليه بالنسبة للمستخدمين الذين يبقون على الكتالوجات الافتراضية. وهذا الاستدلال لا يغطي متغيّر FETCH_HEAD الخاص بـ Gemini CLI، الذي لا يعتمد على كيفية تسمية المضيف للفروع.

كيف يجب أن يبدو الحل

إصلاح AIR الموصى به هو تأكيد واحد: بعد checkout، حدِّد الالتزام الموجود فعليًا في شجرة العمل وأجهض العمل ما لم يكن مطابقًا للـ SHA المثبَّت. ويشدّد الباحثون على أنه يجب فحص HEAD المُحدَّد بدلًا من الـ ref الذي طُلب، لأن هذا التمييز تحديدًا هو ما تتسلل منه نسخة Gemini CLI، وعلى أنه يجب أن يعمل داخل الوكيل، لأن التثبيت يُحدَّد على العميل ولا يمكن لأي سوق أن يفرض الضمان الذي يعلن عنه.

نصائح عملية للفرق التي تشغّل هؤلاء الوكلاء، مستمدة من AIR وCybersecurity News وتعليقات المحللين في InfoWorld:

• حدِّث Claude Code إلى الإصدار 2.1.179 أو أحدث، وCodex إلى الإصدار 0.146.0 أو أحدث. التحديث هو السبيل الوحيد الكامل للتخفيف حيث توجد رقعة.

• عطّل التحديثات التلقائية للإضافات على أي وكيل لا تتوفر له رقعة. فهذا يقلل الثغرة من النقر الصفري إلى إعادة تثبيت يدوية، وهو تقليل للتعرض لا إصلاح له.

• انتقل بعيدًا عن Gemini CLI بدلًا من انتظار تصحيح قالت Google إنه لن يأتي.

• دقّق جرد الإضافات وقيّد مصادر الأسواق حيثما أمكن. يلاحظ AIR أن السوق يمكنه أن يخفّف من متغيّر اسم الفرع بالسماح فقط للمضيفين الذين يرفضون الأسماء على شكل SHA، أي GitHub فقط فعليًا، لكن ذلك يحظر مضيفين يدعمهم الوكلاء رسميًا ولا يفعل شيئًا تجاه متغيّر Gemini.

• تعامل مع محطة العمل باعتبارها حدود التعرّض. فالإضافات ترث أذونات الوكيل، لذا فإن أي استغلال ناجح يصل إلى الشيفرة المصدرية ومفاتيح SSH وبيانات الاعتماد السحابية ورموز CI/CD والمستودعات الداخلية بصلاحية المطوّر نفسه. قال Pareekh Jain، المحلل الرئيسي في Pareekh Consulting، لـ InfoWorld إنه ينبغي لفرق الأمن أن تفحص سجلات EDR وgit وCI/CD وcloud IAM والمصادقة بحثًا عن عمليات غير معتادة، وملفات إضافات غير متوقعة، ومستودعات تغيّرت، ونشاط git مريب — وأضاف أن هذه الخطوات تقلل المخاطر دون إصلاح العيب الأساسي، الذي يعزوه إلى شيفرة البائع. وقال لـ InfoWorld: "يمكن للمؤسسات وضع ضوابط حول استخدام الإضافات، لكنها لا تستطيع إصلاح عيب في طريقة تحقق وكيل البرمجة من الشيفرة التي يسحبها."

لماذا كان خلل التثبيت هو الأمر الذي كان له الأثر الأهم

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

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