Plugin4Shell: كيف تجاوزت ثغرة تثبيت SHA حماية إضافات وكلاء البرمجة بالذكاء الاصطناعي؟

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

كيف يفشل تثبيت SHA؟

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

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

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

لماذا توصف بأنها ثغرة «صفر نقرة»؟

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

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

ما الذي قد يصل إليه المهاجم؟

تنفيذ الشفرة عن بُعد داخل بيئة التطوير قد يمنح المهاجم فعلياً نطاق الوصول نفسه المتاح للمستخدم ولعملية الوكيل. ووفق التغطية المنشورة عن الإفصاح، يمكن أن يشمل ذلك أنظمة الشركة وبياناتها التي يستطيع الموظف المشغّل للوكيل الوصول إليها. 34

عملياً، قد يشمل نطاق الخطر ملفات الشفرة المصدرية المحلية، والمستودعات، وأدوات البناء، ومتغيرات البيئة، وبيانات الاعتماد المتاحة ضمن جلسة المطور. وإذا كانت تلك البيانات تمنح الوصول إلى حسابات سحابية أو خدمات إدارة الشفرة أو أنظمة التكامل والنشر المستمرين (CI/CD) أو أدوات متصلة أخرى، فقد يصبح الجهاز المخترق نقطة انطلاق للوصول الأوسع داخل المؤسسة. ويعتمد حجم الضرر على الصلاحيات والأسرار المتاحة فعلياً للوكيل وحساب المستخدم. 34

حالة المعالجة لدى الموردين

أبلغت Air عن Plugin4Shell في Claude Code وOpenAI Codex وCopilot وGemini CLI. 2

• Anthropic Claude Code: أشارت Air وتغطيات لاحقة إلى أن الإصدار Claude Code 2.1.179 يتضمن إصلاحاً. 12
• OpenAI Codex: أُفيد بأن الإصدار Codex 0.146.0 يتضمن إصلاحاً. 12
• Google Gemini CLI: وصفت التقارير المسار المتأثر في Gemini CLI بأنه مهمل، وقالت إن Google لن تصلح ذلك المسار القديم؛ لذا ينبغي للمستخدمين الانتقال عنه بدلاً من انتظار رقعة. 13
• Microsoft وGitHub Copilot: أدرجت Air منتج Copilot ضمن الوكلاء المتأثرين، لكن الطرح العلني لم يقدم نتيجة واحدة متفقاً عليها بشأن المعالجة. لذلك ينبغي للمؤسسات تقييم منتج Copilot المحدد، وقناة الإضافات أو الامتدادات، وإعدادات التحديث، والضوابط المركزية المفروضة لديها، بدلاً من افتراض أن ما ينطبق على مسار واحد ينطبق على كل بيئات النشر. 234

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

خطوات عملية لتقليل الخطر

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

من الإجراءات الموصى بها:

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

لماذا تتجاوز أهمية Plugin4Shell ثغرة واحدة؟

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

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

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