ثغرة تستهدف “قلب” الحواجز الأمنية في أدوات AI coding
بحسب ما أورده باحثون لدى Adversa، تمس المشكلة آلية تطبيق قواعد “deny” التي يحددها المستخدم لتقييد ما يمكن لـ Claude Code تنفيذه داخل الـ terminal أو عبر shell. هذه القواعد ليست تفصيلاً ثانوياً؛ بل هي خط الدفاع الذي يفترض أن يمنع الوكيل من قراءة ملفات حساسة مثل .env، أو الوصول إلى environment variables التي تحمل API tokens، أو تنفيذ أوامر قد تُحدث تخريباً في الجهاز، أو Git repo، أو بيئة CI/CD. خطورة الثغرة، كما وُصفت، أنها تتيح تمرير أوامر “محظورة” بين قواعد الفلترة بحيث لا تُلتقط بواسطة سياسة الحظر المتوقعة.
“command padding”: خدعة بسيطة… وتأثيرات كارثية
جوهر التقنية التي يتم الحديث عنها هو command padding: تعديل شكل الأمر عبر إضافة مسافات أو رموز أو أجزاء “محايدة” ظاهرياً بهدف تضليل منطق المطابقة الذي يبحث عن patterns ممنوعة. هذا النوع من التحايل معروف في أنظمة تعتمد على فحص نصي مباشر بدل parsing قوي وcanonicalization للمدخلات. فإذا كانت آلية الحظر تقارن strings دون “تطبيع” الإدخال (مثل trim ومعالجة المسافات والاقتباسات وتوحيد الصياغة)، يمكن للمهاجم إنتاج نسخة مكافئة من الأمر تبدو مختلفة للفلتر، لكنها تُنفَّذ فعلياً في shell. ومع AI coding agents، تصبح المشكلة أكثر حساسية لأن الوكيل لا “يقترح” فقط، بل قد ينفّذ.
الأصل التقني: ملف bashPermissions.ts وقرار “تحسين الأداء”
تشير Adversa إلى أن موقع الخلل مرتبط بملف باسم bashPermissions.ts (ضمن نطاق الأسطر 2162–2178). واللافت—كما ورد—أن الدافع كان مرتبطاً بـ performance optimization. هذا النمط مألوف في حوادث الأمن السيبراني الحديثة: تقليل كلفة التحقق أو تبسيط آلية الفحص لتسريع التنفيذ قد يخلق ثغرة غير مقصودة. حتى مع غياب تفاصيل كاملة عن التنفيذ في الملخصات المتداولة، تبقى الرسالة واضحة: الاعتماد على فلترة نصية هشة في سياق أوامر shell ينهار سريعاً أمام إبداع المهاجمين.
لماذا المطورون وفرق DevOps هم الأكثر عرضة؟
تأتي هذه الثغرة في لحظة يتوسع فيها استخدام أدوات مثل Claude Code داخل workflows حقيقية: قراءة وكتابة كود، تنفيذ اختبارات، تثبيت dependencies، تشغيل scripts، وربط ذلك بأنظمة build والتوزيع. هذا التكامل يرفع الإنتاجية، لكنه يوسع سطح الهجوم بشكل كبير. فالأوامر التي ينفذها الوكيل قد تتأثر بمصدر خارجي: prompt، أو issue في tracker، أو README داخل repo، أو حتى dependency تحتوي نصاً موجهاً. ومع وجود ثغرة تتجاوز قواعد deny، يصبح حقن أوامر خبيثة أكثر واقعية—خصوصاً إذا كانت المؤسسة تمنح الوكيل وصولاً إلى أسرار البيئة أو مفاتيح النشر.
من سرقة secrets إلى Supply Chain Compromise
السيناريو الأكثر إثارة للقلق هو الذي يجمع بين الخفاء والأثر. يمكن إغراء الوكيل بتنفيذ أمر يبدو روتينياً، ثم استخلاص مخرجات حساسة: قراءة .env، استخراج SSH keys، أو dump لإعدادات CI، أو استعراض ملفات build. بمجرد تسرب secret واحد، يبدأ “تأثير الدومينو”: دخول إلى private registries، أو repos خاصة، أو خدمات cloud، ثم احتمالية نشر artifact ملوث أو إدخال كود ضار في تحديث اعتيادي. هذا بالضبط ما يجعل ثغرة “تجاوز أمني” داخل أداة AI coding خطرة: إنها لا تضرب ميزة جانبية، بل تضرب آلية التقييد نفسها.
إجراءات عاجلة لتقليل المخاطر قبل أي patch
إلى حين اتضاح الصورة بالكامل وصدور تحديثات، هناك خطوات عملية يمكن لفرق الأمن والهندسة تطبيقها فوراً. أولاً: تقليل الصلاحيات (least privilege) عبر تشغيل Claude Code داخل container أو VM، ومنع الوصول المباشر إلى secrets واستخدام scopes محدودة للـ tokens. ثانياً: الابتعاد عن denylists النصية وحدها، والاتجاه إلى parsing/normalization قوية للأوامر، واعتماد allowlists حيثما أمكن، خصوصاً للأوامر المسموح بها ضمن CI/CD. ثالثاً: تعزيز المراقبة عبر logging مفصل للأوامر التي ينفذها الوكيل، وتفعيل تنبيهات عند الوصول إلى ملفات حساسة، وإجراء audits دورية. وفي البيئات عالية الحساسية، قد تكون rotation استباقية لبعض secrets خطوة مبررة إذا كان هناك احتمال لاستخدام مسارات تنفيذ معرضة للخطر.
درس للصناعة: AI agents أدوات إنتاج… وأيضاً أدوات “إدارة نظام”
تكشف الواقعة عن مفارقة أساسية في سباق AI applied to code: كلما صار الوكيل أكثر “فائدة” وقدرة على الفعل داخل النظام، أصبح أصلاً حرجاً يجب تحصينه كما لو كان أداة sysadmin كاملة الصلاحيات. المطلوب ليس فقط ترقيع ثغرة بعينها، بل ترسيخ معايير Security by Design: تطبيع المدخلات بشكل صارم، فصل الأدوار، sandboxing حقيقي، وضوابط تنفيذ قابلة للتدقيق. في عصر تتزايد فيه أتمتة التطوير عبر copilots وagents، الثقة لا تُبنى على قوة النموذج وحدها، بل على صلابة guardrails التي تمنع “أمر واحد” من تحويل pipeline بأكمله إلى نقطة اختراق.
