في واحدة من أكثر قصص أمن المعلومات غرابة هذا العام، كشفت شركة الأمن السيبراني Wiz يوم 17 أغسطس 2026 أن وكيلها الأمني الذكي Red Agent نجح في اكتشاف واستغلال ثغرة حقيقية في مستودع مفتوح المصدر تابع لشركة Snowflake، ووصل إلى نظام Jira الداخلي للشركة وسطّر بيانات اعتماد حساسة، كل ذلك دون تدخل بشري واحد. والقصة الأكثر إثارة للجدل: الكود الذي فتح الباب للثغرة كان قد اجتاز فحصاً واعتماداً من Copilot، مساعد البرمجة الذكي من مايكروسوفت وGitHub.
ماذا حدث بالضبط؟
الباحث غال ناغلي من فريق Wiz Research وثّق السلسلة كاملة في تدوينة رسمية على موقع الشركة. المستهدف كان المستودع المفتوح snowflake-connector-net الخاص بموصل Snowflake لمنصة .NET، وتحديداً ملف سير عمل GitHub Actions باسم jira_issue.yml.
الثغرة من فئة script injection، أي حقن أوامر عبر مدخلات غير موثوقة داخل كتل shell. كشف الفحص أن طلب دمج رقم 1218، الذي دُمج بلقطة commit تحمل المعرف 4a1b8ce، استبدل نمطاً آمناً كان يمرر عنوان القضية عبر متغير بيئة مع jq --arg، باستيفاء مباشر للقيمة داخل أمر shell بصيغة ${{ github.event.issue.title }}. النتيجة: مجرد علامة اقتباس مفردة في عنوان قضية على GitHub تكفي للخروج من نص الأمر وتنفيذ أي أوامر إضافية يريدها المهاجم.
والمفارقة التي جعلت القصة تتصدر النقاشات التقنية أن اللقطة المدمجة تحمل توقيع مشارك مؤتمت مكتوب فيه حرفياً «Copilot Autofix powered by AI»، وأن Copilot فحص طلب الدمج ووافق عليه وأعطاه إشارة السلامة الخضراء قبل دمجه. كما كانت بوابة الحماية المفترضة معطلة ببساطة: شرط التنفيذ في سير العمل كان يفحص حقل github.event.pull_request.user.login الذي يساوي دائماً قيمة فارغة في أحداث القضايا، فكان الفحص يجتاز دائماً بشكل صامت. تكشف Wiz أنها لا تستطيع الجزم إن كان التغيير الخطِر نفسه مكتوباً بالذكاء الاصطناعي أم لا، لكن المؤكد أن مراجعة Copilot مرّت عليه دون أن تكتشفه.
كيف اخترق الوكيل الذكي Jira الداخلية؟
سلسلة الهجوم كما وثّقتها Wiz تفصيلياً تكشف مستوى وكيلاً ذاتياً يعمل بحرية بحثية كاملة:
- الاكتشاف: ماسح الوكيل لثغرات CI/CD رصد النمط الخطِر في سير العمل أثناء مسحه الآلي للمستودعات.
- الهجوم الأول والفشل: فتح الوكيل قضية على GitHub بعنوان مصمم بعناية كحمولة حقن. المحاولة الأولى فشلت بخطأ bash unexpected EOF لأن حمولته استخدمت محرف التعليق الذي التهم قوس الإغلاق.
- التشخيص الذاتي: دون أي تدخل بشري، قرأ الوكيل رسالة الخطأ، فهم سببها، وأعاد صياغة الحمولة باستخدام
; echo 'لإغلاق كتلة shell بشكل صحيح. - الاستخراج: الحمولة الناجحة سحبت ثلاثة أسرار مشفرة بترميز base64 وأرسلتها إلى مستقبل خارجي عبر خدمة oast.me، من عنوان IP على أزور هو 20.106.182.197. الأسرار كانت رمز JIRA_API_TOKEN وبريد JIRA_USER_EMAIL وعنوان JIRA_BASE_URL.
- الوصول: الرمز المصادر سمح بالدخول بحساب [email protected] إلى نظام snowflakecomputing.atlassian.net التابع لـ Snowflake، وفتح صلاحيات قراءة لمشاريع تتبع الهندسة والامتثال الأمني وبرنامج مكافآت اكتشاف الثغرات.
المصدر: Wiz Blog — Red Agent Snowflake Copilot CI/CD bug
الخط الزمني الكامل كما وثقته Wiz
| التاريخ | الحدث |
|---|---|
| 18 يونيو 2026 | دمج طلب الدمج رقم 1218 وإدخال الثغرة إلى سير العمل |
| 23 يونيو 2026 | Wiz تكتشف وتستغل وتبلغ عبر HackerOne بالتقرير رقم 3819931 وإشعار Slack |
| 23 يونيو 2026 | Snowflake ترقع في اليوم نفسه عبر الالتزام 1dc7766 في طلب الدمج 1402 بإعادة النمط الآمن |
| 24 يونيو 2026 | تدوير رمز Jira المسرّب |
| 25 يوليو 2026 | الموعد النهائي للإفصاح العام وفق سياسة الثلاثين يوماً |
| 17 أغسطس 2026 | النشر التفصيلي مع تحديث توضيحي في 19:57 UTC |
الأهم في الجدول هو نافذة التعرض: الثغرة عاشت خمسة أيام فقط من دمجها حتى الإبلاغ والترقيع. وتؤكد سجلات التدقيق الجنائي لـ Snowflake أن Wiz كانت الفاعل الوحيد خلال نافذة التعرض، دون أي دليل على وصول غير مصرح به من طرف ثالث، وأن جميع البيانات التي وصل إليها الباحثون في إثبات المفهوم حُذفت بأمان.
وقالت Snowflake في ردها المعلن إن التقرير عولج وفحص فوراً، وإن التحقيق لم يجد أي دليل على وصول غير مصرح به، مقدمة شكرها لفريق Wiz على الإبلاغ المنضبط. ولم يصدر عن GitHub أو مايكروسوفت رد موثق ضمن التدوينة وقت نشرها.
المصدر: Wiz Blog — Red Agent Snowflake Copilot CI/CD bug
لماذا القصة أكبر من ثغرة واحدة؟
هذه ليست مجرد ثغرة رُقعت. القصة نموذج مصغر لثلاث تحولات كبيرة تخص كل فريق تقني:
أولاً، الذكاء الاصطناعي يكتشف أخطاء الذكاء الاصطناعي. كود دمج آلي بمراجعة آلية لم تكتشف ثغرة قابلة للاستغلال، ووكيل ذكي آخر اكتشفها واستغلها لإثبات الخطورة. الدورة التي كانت تتطلب فريق بحث بشري وأسابيع عمل اكتملت في جلسات آلية. وهذا يتقاطع مع اتجاه وثقناه مراراً هذا العام، من حوادث التقييمات الأمنية لـ Claude إلى تحذيرات OpenAI من اقتراب نموذج Astra من عتبة القدرات السيبرانية الحرجة والحوادث الأمنية التي رافقت تقييمات الجهات الخارجية لنماذجها.
ثانياً، نوافذ الاكتشاف تنهار. حين كان المهاجمون البشر يمسحون المستودعات المفتوحة يدوياً، كانت الثغرات تعيش شهوراً قبل أن يستغلها أحد. حين صار الماسح وكيل ذكاء اصطناعي يعمل على مدار الساعة، صار متوسط عمر الثغرة غير المرئية أياماً أو ساعات. الاستنتاج العملي الذي تخلص له Wiz صريح: الترقيع السريع وبيانات الاعتماد قصيرة العمر لم تعدا رفاهية أمنية بل شرط بقاء.
ثالثاً، الكود المولد آلياً يحتاج مراجعة بشرية كاملة، لا شكلية. الخطأ هنا لم يكن في قدرات Copilot على توليد الأكواد بل في ثقة فريق بأي بوابة فحص آلية كافية لاستبعاد المراجعة البشرية. والتوصية التقنية الأدق التي خرجت بها القصة: امنع الوكلاء الذكيين من استبدال المحللات المنظمة كالمتغيرات البيئية مع jq بالاستيفاء النصي المباشر، فهذا النمط تحديداً هو ما حوّل عنوان قضية بريئاً إلى أمر تنفيذي.
ماذا يعني هذا لك؟
إن كنت تدير فريقاً تقنياً أو أمنياً في المنطقة، ثلاث خطوات عملية تفرضها القصة هذا الأسبوع لا الشهر القادم: راجع كل سير عمل GitHub Actions لديكم بحثاً عن أي استيفاء مباشر لقيم github.event داخل كتل shell، فهذا الفحص يستغرق دقائق بأدوات فحص ثابتة جاهزة؛ وفعّل سياسة رموز وصول قصيرة العمر بحيث لا يعني تسريب رمز واحد نافذة وصول ممتدة؛ وأعد تعريف بوابة دمج الكود الآلي بحيث يبقى مراجع بشري إلزامياً لأي تغيير يمس سير العمل أو البنية التحتية، مهما كانت إشارة الفحص الآلي مطمئنة.
حدود القصة التي يجب قولها
- لا يوجد ضرر فعلي: الوصول كان لإثبات مفهوم بحثي ضمن إفصاح مسؤول، والبيانات حُذفت، ولا دليل على استغلال من أطراف أخرى.
- إدانة Copilot غير دقيقة: ما وثقته Wiz أن Copilot فحص ووافق على الكود، وليس أنه كتب الكود الخطِر بنفسه، فاحتمال كتابته بشرية وارد وغير محسوم.
- نموذج التهديد محدد: الثغرة في سير عمل CI/CD لمستودع مفتوح المصدر، ولا تعمم تلقائياً على كل استخدام لـ Copilot.
- الباحث نفسه صاحب المصلحة في القصة: Wiz تبيع منصة أمن السياق السيبراني للسحابة، وهذا لا يلزم دقة البحث الموثق لكنه سياق يستحق العلم.
أسئلة شائعة
هل اختُرق نظام Snowflake الإنتاجي؟
لا. الوصول كان عبر رمز حساب اختباري [email protected] إلى نظام Jira الداخلي بصلاحيات قراءة لمشاريع الهندسة والامتثال ومكافآت الثغرات، ضمن إفصاح أمني مسؤول، وقد أكدت Snowflake عدم وجود دليل على وصول غير مصرح به من أي طرف ثالث.
ما دور Copilot في الثغرة؟
طلب الدمج الذي أدخل الكود الخطِر يحمل توقيع Copilot Autofix كمساعد، وقد فحص Copilot الطلب ووافق عليه دون اكتشاف الثغرة. أما هل كتب Copilot السطر الخطِر نفسه فأمر لم تحسمه Wiz صراحة.
هل يمكن تكرار الهجوم على مستودعات أخرى؟
نعم من حيث المبدأ. نمط حقن الأوامر عبر عناوين القضايا في سير عمل GitHub Actions معروف ومصنف في قواعد OWASP الخاصة بسير العمل، وأدوات الفحص الثابتة تكشفه، والدفاع هو منع الاستيفاء المباشر للمدخلات داخل كتل shell.
ما هو Red Agent؟
وكيل بحث هجومي ذاتي طورته Wiz يكتشف الثغرات ويفحصها ويستغلها لإثبات الأثر دون تدخل بشري، وقد قام بكامل سلسلة هذا الاكتشاف من المسح حتى إثبات الوصول.
ما الذي ينبغي على الفرق فعله الآن؟
فحص كل مسارات GitHub Actions للبحث عن استيفاء مباشر لمدخلات الأحداث داخل أوامر shell، وقصر صلاحيات الأسرار المستخدمة في سير العمل، وتقصير أعمار الرموز، وإبقاء مراجعة بشرية إلزامية لتغييرات البنية التحتية مهما كانت نتائج الفحص الآلي.
المصادر:
- Wiz Blog — Red Agent Snowflake Copilot CI/CD bug (17 أغسطس 2026)
- المستودع المتأثر snowflakedb/snowflake-connector-net على GitHub
