كيف يعمل الهجوم

وصف الباحثون نمط سير العمل الذكي الضعيف في GitHub بأنه:

• يتم تفعيله عند وقوع أحداث issues.assigned.
• يقرأ عنوان الإصدار ومحتواه.
• ينشر تعليقًا باستخدام أداة وكيل مثل add-comment.
• يعمل بصلاحيات قراءة لمستودعات أخرى في المؤسسة، بما في ذلك المستودعات الخاصة.

يتكون الهجوم من أربع خطوات:

1. يفتح المهاجم إصدار GitHub يبدو بريئًا في مستودع عام تابع لمؤسسة تستخدم نمط سير العمل الذكي الضعيف.
2. داخل محتوى الإصدار، توجد أوامر باللغة الإنجليزية البسيطة توجه الوكيل الذكي لجلب ملفات من مستودعات خاصة.
3. عندما يقوم نظام GitHub الآلي بتعيين الإصدار، يتسبب سير العمل المُفعّل بالحدث في قيام الوكيل بجلب بيانات من المستودعات التي يمكنه الوصول إليها، بما في ذلك المستودعات الخاصة.
4. ينشر الوكيل المحتويات التي تم جلبها كـ تعليق عام على الإصدار، مما قد يعرض البيانات لأي شخص يمكنه رؤية الإصدار.

الضعف المعماري الأساسي

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

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

قام الباحثون بتصنيف هذه الفئة من الثغرات رسميًا باسم "حقن سير العمل الوكيل" (Agentic Workflow Injection - AWI)، وحددوا نمطين أساسيين: "موجه إلى وكيل" (Prompt-to-Agent - P2A)، حيث يصل المحتوى غير الموثوق إلى حدود موجه الوكيل، و"موجه إلى سكريبت" (Prompt-to-Script - P2S)، حيث ينتشر تأثير المهاجم عبر المخرجات المشتقة من النموذج إلى سكريبتات لاحقة.

تقنية تجاوز الحواجز: كلمة "Additionally"

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

يتوافق هذا الأسلوب مع أبحاث أوسع في مجال حقن الأوامر تُظهر أن صياغة معينة أو نصًا يتم إرجاعه بواسطة أداة يمكن أن يتسبب في اتباع النماذج لتعليمات ضارة كان ينبغي لها ألا تتبعها. يعكس تجاوز الحاجز أنماطًا شوهدت في حوادث سابقة، مثل ثغرة GitHub MCP التي كشفت عنها Invariant Labs، حيث يمكن لإصدار ضار اختطاف وكيل مستخدم لتسريب بيانات من مستودعات خاصة.

التوصيات للتخفيف من المخاطر

بناءً على نتائج GitLost والإرشادات الأوسع لأمن سير العمل الوكيل، يجب على المؤسسات المتأثرة تنفيذ الضوابط التالية:

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

يجب على المؤسسات أيضًا تطبيق مبدأ الامتياز الأقل على أسرار الوكيل وتنفيذ مراقبة أمنية مستمرة لمحاولات حقن الأوامر.

استجابة GitHub (حتى 7 يوليو)

وفقًا لـ Dark Reading والجدول الزمني للإفصاح من Noma Security:

• قامت Noma بالإفصاح المسؤول عن الثغرة لـ GitHub.
• أخبرت GitHub شركة Noma أنها قامت بتحديث الوثائق المرتبطة بنمط سير العمل الضعيف، وأفاد الباحثون أن التكوين الضعيف لم يعد موجودًا عندما قاموا بفحصه آخر مرة.
• اعتبارًا من 7 يوليو، لم تصدر GitHub بيانًا عامًا رسميًا أو CVE لثغرة GitLost.
• يبدو أن الثغرة قد تمت معالجتها جزئيًا من خلال إزالة أو مراجعة الوثائق وقالب سير العمل الممكّن، بدلاً من إصلاح أمني واضح على مستوى المنصة.

الصورة الأكبر: خطر منهجي

GitLost ليست حادثة معزولة. إنها تمثل فئة متنامية من الثغرات حيث يتم تعريض وكلاء الذكاء الاصطناعي الذين لديهم إمكانية الوصول إلى بيانات حساسة لمحتوى مستخدم غير موثوق. مشكلات مماثلة أثرت على تكاملات GitHub MCP، وسير عمل Google's Gemini CLI (ثغرة TrustIssues)، و Claude Code GitHub Actions. الخيط المشترك هو أن الوكلاء القائمة على LLM يفتقرون إلى قدرة متأصلة على التمييز بين البيانات والتعليمات عندما يظهر كلاهما في نفس نافذة السياق — وهو تحدٍ معماري أساسي لا يمكن لأي تصحيح منفرد للمنصة حله بالكامل.

كيف يعمل الهجوم

وصف الباحثون نمط سير العمل الذكي الضعيف في GitHub بأنه:

• يتم تفعيله عند وقوع أحداث issues.assigned.
• يقرأ عنوان الإصدار ومحتواه.
• ينشر تعليقًا باستخدام أداة وكيل مثل add-comment.
• يعمل بصلاحيات قراءة لمستودعات أخرى في المؤسسة، بما في ذلك المستودعات الخاصة.

يتكون الهجوم من أربع خطوات:

1. يفتح المهاجم إصدار GitHub يبدو بريئًا في مستودع عام تابع لمؤسسة تستخدم نمط سير العمل الذكي الضعيف.
2. داخل محتوى الإصدار، توجد أوامر باللغة الإنجليزية البسيطة توجه الوكيل الذكي لجلب ملفات من مستودعات خاصة.
3. عندما يقوم نظام GitHub الآلي بتعيين الإصدار، يتسبب سير العمل المُفعّل بالحدث في قيام الوكيل بجلب بيانات من المستودعات التي يمكنه الوصول إليها، بما في ذلك المستودعات الخاصة.
4. ينشر الوكيل المحتويات التي تم جلبها كـ تعليق عام على الإصدار، مما قد يعرض البيانات لأي شخص يمكنه رؤية الإصدار.

الضعف المعماري الأساسي

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

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

قام الباحثون بتصنيف هذه الفئة من الثغرات رسميًا باسم "حقن سير العمل الوكيل" (Agentic Workflow Injection - AWI)، وحددوا نمطين أساسيين: "موجه إلى وكيل" (Prompt-to-Agent - P2A)، حيث يصل المحتوى غير الموثوق إلى حدود موجه الوكيل، و"موجه إلى سكريبت" (Prompt-to-Script - P2S)، حيث ينتشر تأثير المهاجم عبر المخرجات المشتقة من النموذج إلى سكريبتات لاحقة.

تقنية تجاوز الحواجز: كلمة "Additionally"

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

يتوافق هذا الأسلوب مع أبحاث أوسع في مجال حقن الأوامر تُظهر أن صياغة معينة أو نصًا يتم إرجاعه بواسطة أداة يمكن أن يتسبب في اتباع النماذج لتعليمات ضارة كان ينبغي لها ألا تتبعها. يعكس تجاوز الحاجز أنماطًا شوهدت في حوادث سابقة، مثل ثغرة GitHub MCP التي كشفت عنها Invariant Labs، حيث يمكن لإصدار ضار اختطاف وكيل مستخدم لتسريب بيانات من مستودعات خاصة.

التوصيات للتخفيف من المخاطر

بناءً على نتائج GitLost والإرشادات الأوسع لأمن سير العمل الوكيل، يجب على المؤسسات المتأثرة تنفيذ الضوابط التالية:

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

يجب على المؤسسات أيضًا تطبيق مبدأ الامتياز الأقل على أسرار الوكيل وتنفيذ مراقبة أمنية مستمرة لمحاولات حقن الأوامر.

استجابة GitHub (حتى 7 يوليو)

وفقًا لـ Dark Reading والجدول الزمني للإفصاح من Noma Security:

• قامت Noma بالإفصاح المسؤول عن الثغرة لـ GitHub.
• أخبرت GitHub شركة Noma أنها قامت بتحديث الوثائق المرتبطة بنمط سير العمل الضعيف، وأفاد الباحثون أن التكوين الضعيف لم يعد موجودًا عندما قاموا بفحصه آخر مرة.
• اعتبارًا من 7 يوليو، لم تصدر GitHub بيانًا عامًا رسميًا أو CVE لثغرة GitLost.
• يبدو أن الثغرة قد تمت معالجتها جزئيًا من خلال إزالة أو مراجعة الوثائق وقالب سير العمل الممكّن، بدلاً من إصلاح أمني واضح على مستوى المنصة.

الصورة الأكبر: خطر منهجي

GitLost ليست حادثة معزولة. إنها تمثل فئة متنامية من الثغرات حيث يتم تعريض وكلاء الذكاء الاصطناعي الذين لديهم إمكانية الوصول إلى بيانات حساسة لمحتوى مستخدم غير موثوق. مشكلات مماثلة أثرت على تكاملات GitHub MCP، وسير عمل Google's Gemini CLI (ثغرة TrustIssues)، و Claude Code GitHub Actions. الخيط المشترك هو أن الوكلاء القائمة على LLM يفتقرون إلى قدرة متأصلة على التمييز بين البيانات والتعليمات عندما يظهر كلاهما في نفس نافذة السياق — وهو تحدٍ معماري أساسي لا يمكن لأي تصحيح منفرد للمنصة حله بالكامل.