وكيل أمن بالذكاء الاصطناعي اخترق Snowflake. قصة Copilot كانت ضجيجاً.

دخل وكيل ذكاء اصطناعي إلى Jira الداخلي لدى Snowflake في يونيو، والجزء الذي تصدرت به معظم التغطية كان الجزء الخطأ. النسخة الأولى من القصة قالت إن GitHub Copilot كتب الشفرة الضعيفة، وهي حكاية مرتبة عن ذكاء اصطناعي يفسد ما كتبه ذكاء اصطناعي. لم تصمد هذه النسخة سوى ساعات. صححت Wiz إفصاحها في اليوم نفسه، ورفضت GitHub نسبة التأليف صراحة، وما يبقى بعد التصحيح أغرب وأنفع: وكيل مستقل وجد ثغرة حية، وكتب استغلالاً لها، وصحح حمولة فاشلة من صنعه، واستخرج بيانات اعتماد صالحة، من البداية إلى النهاية، بينما لم تر الماسحات التقليدية التي فحصت الشفرة نفسها شيئاً. هذه هي القصة التي تستحق وقتك.

أهم الخلاصات - وجد Red Agent من Wiz، وهو وكيل مستقل للأمن الهجومي، حقن سكربت في سير عمل GitHub Actions داخل مستودع Snowflake العام snowflake-connector-net، واستغله لسرقة رمز Jira. لم يلمس إنسان لوحة المفاتيح بين اكتشاف الثغرة وتسريب بيانات الاعتماد. - دخلت الثغرة الخدمة في 18 يونيو 2026، وعُثر عليها واستُغلت وأُبلغ عنها في 23 يونيو، وكل ذلك من خلال برنامج HackerOne لدى Snowflake. أصلحت Snowflake الثغرة في اليوم نفسه، وتظهر سجلات التدقيق أن Wiz كانت الفاعل الوحيد خلال فترة التعرض. - تراجع الادعاء الأول بأن Copilot كتب الخطأ خلال ساعات. كان النمط الضعيف في تغيير كتبه إنسان؛ وكانت المساهمة الموثقة لـ Copilot Autofix في ملف آخر، أما وسم المؤلف المشترك فكان أثراً لعملية squash merge. - فحص GitHub Advanced Security النسخة الضعيفة نفسها وفاته الخطأ. ماسح يعتمد على مطابقة الأنماط نظر إلى الشفرة نفسها التي استدل فوقها وكيل، وواحد منهما فقط فهمها. - الجزء الوكيلي فعلاً كان ضيقاً لكنه حقيقي: تشخيص استغلال فاشل وإعادة كتابته. الباقي أتمتة جيدة بداخلها نموذج لغوي.

ماذا حدث؟

الخط الزمني، كله من إفصاح Wiz ورد Snowflake عليه:

• 18 يونيو 2026. دُمج طلب السحب #1218 في snowflakedb/snowflake-connector-net، مستودع موصل .NET العام لدى Snowflake. أعاد الطلب كتابة سير عمل باسم jira_issue.yml، ينشئ تذاكر Jira تلقائياً عندما يفتح شخص مشكلة على GitHub. استبدلت إعادة الكتابة نمطاً آمناً، تمرير عنوان المشكلة عبر متغير بيئة إلى jq --arg، بإدراج العنوان مباشرة داخل كتلة shell من نوع run:.

• 23 يونيو. أثناء مسح مؤسسة Snowflake على GitHub ضمن برنامج مكافآت الثغرات HackerOne، صنف Red Agent سير العمل على أنه قابل للحقن. بنى استغلالاً وأطلقه، واصطدم بخطأ في صياغة shell داخل حمولته، وشخّص الخطأ، وأعاد كتابة الحمولة، ونجح في المحاولة الثانية. أعاد GitHub Actions runner مستضاف على Azure اتصالاً إلى مستمع Wiz يحمل رمز Jira API مشفراً بـ base64 ومرتبطاً بحساب خدمة. أبلغت Wiz عنه عبر HackerOne في اليوم نفسه.

• 23 يونيو، في اليوم نفسه. أصلحت Snowflake سير العمل وأعادت النمط الآمن.

• 24 يونيو. سُحب رمز Jira ودُوّر. لم تجد مراجعة Snowflake لسجلات التدقيق أي وصول من جهة غير Wiz خلال نافذة التعرض التي استمرت خمسة أيام. وتقول Wiz إنها حذفت البيانات من إثبات المفهوم.

• 17 أغسطس. نشرت Wiz التقرير بقلم Gal Nagli، رئيس قسم التعرض للتهديدات في Wiz Research، ثم حدثته عند 19:57 UTC في اليوم نفسه لتوضيح أن Copilot كان مؤلفاً مشاركاً فحص طلب السحب المدمج ومرره، وأنه غير واضح ما إذا كان التغيير الضعيف استعان بالذكاء الاصطناعي أصلاً.

كان الرمز يحمل صلاحية قراءة Jira الداخلي لدى Snowflake: الهندسة، والامتثال الأمني، وبرنامج مكافآت الثغرات نفسه. لم تُمس أي بيانات عملاء، ولم يتأثر الموصل المشحون للمستخدمين.

في 23 يونيو 2026، وجد Red Agent المستقل من Wiz واستغل حقن سكربت في سير عمل GitHub Actions داخل مستودع snowflake-connector-net لدى Snowflake، وسرّب رمز Jira بصلاحية قراءة إلى مشروعات الهندسة والامتثال الأمني ومكافآت الثغرات الداخلية، بعد خمسة أيام من دخول الثغرة الخدمة ومن دون تدخل بشري، وفق إفصاح Wiz Research. أصلحت Snowflake الخلل في اليوم نفسه ولم تجد وصولاً من أطراف ثالثة في سجلات التدقيق.

سلسلة الصلاحيات، حلقة بعد أخرى

الاستغلال درس مرتب في مقدار الثقة التي تحملها خطوط CI بصمت. تتبع ما استطاع عنوان مشكلة مصاغ بعناية الوصول إليه:

1. المشغّل. كان سير العمل يعمل على issues: opened، ما يعني أن أي حساب GitHub في العالم يستطيع تشغيله بفتح مشكلة. وكان شرط يفترض أنه يقيد الوصول يُقيّم دائماً إلى true عند أحداث فتح المشكلات، وفق التغطية التقنية.

2. الحقن. نفذت الشفرة الجديدة TITLE=$(echo '${{ github.event.issue.title }}' | sed ...). يوسع GitHub قالب ${{ }} قبل تشغيل shell، لذلك يصل الهروب الذي ينفذه sed متأخراً. علامة اقتباس مفردة واحدة في العنوان تغلق السلسلة، ويُنفذ ما تبقى من العنوان كأوامر shell.

3. البيئة. تعمل الأوامر الآن داخل GitHub Actions runner، وهو جهاز مليء ببيانات الاعتماد بحكم التصميم. كان هذا يحمل رمز Jira API لحساب خدمة، لأن مهمة سير العمل كلها هي إنشاء تذاكر Jira.

4. التسريب. شفرت الحمولة الرمز بـ base64 وأرسلته إلى مستمع Wiz عبر اتصال خارج القناة، لذلك لم يظهر شيء مريب في سجلات سير العمل.

5. الجائزة. وثق الرمز الدخول إلى بيئة Atlassian الداخلية لدى Snowflake بصلاحية قراءة تشمل مشروعات الهندسة والامتثال الأمني ومكافآت الثغرات.

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

جمع الاستغلال خمس طبقات من الثقة المشروعة: مشكلة GitHub بلا مصادقة شغلت سير العمل، وحقن بعلامة اقتباس مفردة خرج من shell، وبيئة الـ runner احتوت رمز حساب خدمة لـ Jira، واتصال خارج القناة سرّبه، ثم فتح الرمز صلاحية قراءة Jira الداخلي لدى Snowflake. يوسع GitHub القالب قبل تنفيذ الهروب في shell، ولذلك وصل التعقيم متأخراً، وفق تقرير Wiz.

ما الذي كان وكيلياً وما الذي لم يكن؟

أريد الدقة هنا، لأن عبارة «وكيل ذكاء اصطناعي يخترق Snowflake» تدعو إلى قراءتين كسولتين: أن هذا مجرد ماسح بتسويق أفضل، أو أن Skynet انفلت. لا تصمد أي منهما أمام التفاصيل.

أتمتة عادية بداخلها نموذج. المسح والفرز. قدرة Red Agent على CI/CD تزحف عبر مؤسسات GitHub بحثاً عن ملفات سير عمل تُدرج مدخلات غير موثوقة داخل كتل run:. هذه فئة ثغرات مفهومة جيداً ولها شكل معروف، ووضع علامة على jira_issue.yml شيء يمكن لقاعدة تحليل ساكن جيدة أن تفعله بصورة معقولة. اختيار الهدف وقراءة سير العمل والحكم بأنه قابل للاستغلال مهارة، لكنها قريبة مما تبيعه Wiz بالفعل كإدارة مستمرة لسطح الهجوم.

وكيلي فعلاً. حلقة الاستغلال. استخدمت الحمولة الأولى للوكيل محرف تعليق كسر صياغة shell وفشلت. قرأ خطأ bash الناتج، وفهم سبب تشوه الحمولة، وأعاد كتابتها لإغلاق السكربت بصورة صحيحة، ونجح في المحاولة الثانية. ثم تحقق من أن الرمز المسروق يعمل فعلاً ضد Jira لدى Snowflake وقيّم ما يستطيع الوصول إليه. تشخيص فشل وقت تشغيل جديد في هجومك أنت والتكيف معه من دون طلب ليس مطابقة توقيع. هذه الحلقة، حاول ثم راقب ثم صحح، هي ما يفصل الوكيل عن الماسح، وهي الحلقة نفسها التي كتبت عنها عموماً في المعمارية الوكيلية. رؤيتها تعمل هجومياً، ضد هدف من Fortune 500، بلا إشراف، سابقة تستحق الملاحظة.

ليس الوكيل إطلاقاً. النطاق والأخلاقيات والإفصاح. عمل Red Agent داخل برنامج HackerOne لدى Snowflake، أي ضمن نطاق اختاره إنسان في Wiz وصرح به. الاستقلالية كانت حقيقية لكنها محدودة ومصرحاً بها ومراقبة، وهذه بالضبط النقطة التي ينبغي أن يشدد عليها المدافعون. أطلقت Wiz خدمة Red Agent في مارس وأتاحتها عموماً في أواخر يوليو، وهي مبنية جزئياً على Claude Opus من Anthropic. أصبحت القدرة الآن منتجاً يمكن لأي فريق أمن استئجاره، لذلك النسخة الهجومية من هذه الحلقة على وشك أن تصبح شائعة جداً.

كان مسح Red Agent وفرزه أتمتة بداخلها نموذج؛ أما النواة الوكيلية فكانت حلقة الاستغلال: عندما ألقت حمولته الأولى خطأ في صياغة shell، شخّص الوكيل فشل bash وأعاد كتابة الحمولة ونجح في المحاولة الثانية، ثم تحقق من الرمز وحدد نطاق ضرره، كله من دون مساعدة بشرية، وفق إفصاح Wiz.

سطر Copilot هو الجزء الأقل إثارة للاهتمام

قالت العناوين الأولى إن Copilot كتب الخطأ. السجل يقول غير ذلك. المساهمة الموثقة لـ Copilot Autofix في طلب السحب #1218 كانت إصلاحاً منفصلاً في ملف مختلف، jira_close.yml. أما الإدراج الضعيف فكان في التزام منسوب إلى مهندس مسمّى في Snowflake، وقالت GitHub للصحفيين إن مراجعتها الداخلية وجدت أن Copilot Autofix لم يكتب هذه الأسطر ولم يراجعها. كان وسم «شارك Copilot في التأليف» على طلب السحب المدمج أثراً لعملية squash merge سحبت التذييل معها. عدلت Wiz منشورها في اليوم نفسه؛ وصححت The Register قصتها. تعليق Ami Luttwak، المدير التقني في Wiz، لـ CSO هو الخلاصة الصادقة: عندما تعمل عدة وكلاء على كل طلب سحب، فإن «مجرد النظر إلى المؤلفين المشاركين في طلب السحب لا يكفي» لتحديد من كتب ماذا.

يمكن لحقيقتين أن تكونا صحيحتين معاً. فحص GitHub Advanced Security، الذي يستخدم Copilot Autofix، النسخة النهائية لذلك الطلب بما فيها سير العمل الضعيف ولم يضع علامة على الحقن؛ هذا موجود في رواية Wiz ولم تنكره GitHub. وفي الوقت نفسه، الادعاء المحدد بأن Copilot ألّف الثغرة غير مدعوم. مراجعة بمساعدة الذكاء الاصطناعي فاتتها ثغرة حرجة في شفرة مررتها على أنها سليمة. هذه قصة حقيقية عن حدود مراجعة الذكاء الاصطناعي؛ لكنها ليست قصة عن ذكاء اصطناعي كتب الخطأ، والخلط بين الاثنين لا يساعد أحداً يحاول تحديد مقدار الثقة التي يضعها في مراجعة الذكاء الاصطناعي لطلبات السحب لديه.

أوحت Wiz أولاً بأن Copilot ساعد في كتابة الشفرة الضعيفة، ثم أوضحت في اليوم نفسه أن المساهمة الموثقة لـ Copilot Autofix كانت في ملف آخر داخل طلب السحب نفسه، وأن وسم المؤلف المشترك كان أثراً لعملية squash merge. تقول GitHub إن مهندساً بشرياً كتب إعادة الهيكلة المعيبة وإن Copilot لم يراجعها. ما لا خلاف عليه: فحص GitHub Advanced Security النسخة الضعيفة ولم يضع علامة على شيء، وفق منشور Wiz المحدث وتغطية CSO.

ماذا ينبغي أن تفعل الآن؟

إذا كنت تشغّل GitHub Actions وتوجد فيه أي أسرار، فافعل هذا هذا الأسبوع:

1. ابحث في تدفقات العمل عن ${{ github.event.* }} داخل كتل run:. أي إدراج لعناوين المشكلات أو طلبات السحب أو أسماء الفروع أو أجسام التعليقات في shell قابل للحقن، بلا استثناء. انقل القيمة إلى متغير env: ومررها باقتباس صحيح، أو حللها باستخدام jq --arg. هذا هو النمط الذي أعادته Snowflake.

2. افترض أن الـ runners مخازن لبيانات الاعتماد. قلّص رموز سير العمل إلى الحد الأدنى، وفضل بيانات اعتماد OIDC قصيرة العمر على رموز حسابات الخدمة طويلة العمر، وتعامل مع أي سير عمل تشغله أحداث غير موثوقة، مثل issues وpull_request_target والتعليقات، كأنه شفرة مكشوفة للإنترنت.

3. لا تجعل مراجعة الذكاء الاصطناعي خط دفاعك الأخير. ماسح GitHub نفسه نظر إلى هذه الشفرة بالضبط ومررها. ضع طبقات من الفحوص، وكن متشككاً في أي سير عمل تُفوض فيه المراجعة والتأليف والمسح كلها إلى نماذج المورد نفسه.

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

الأسئلة الشائعة

هل كتب GitHub Copilot ثغرة Snowflake؟

لا، ليس وفق الأدلة الحالية. كان Copilot Autofix مؤلفاً مشاركاً في طلب السحب المدمج، لكن تغييره الموثق كان في ملف آخر، وكان الوسم أثراً لعملية squash merge، وتقول GitHub إن مهندساً بشرياً كتب الشفرة الضعيفة. ما هو صحيح: فحص GitHub Advanced Security النسخة الضعيفة وفاته الحقن.

كيف دخل وكيل Wiz إلى Jira لدى Snowflake؟

وجد سير عمل يدرج عناوين المشكلات مباشرة داخل سكربت shell. فتح مشكلة بعنوان مصاغ بعناية شغّل أوامر عشوائية على الـ runner، الذي كان يحمل رمز حساب خدمة لـ Jira. سرّب الوكيل الرمز عبر اتصال خارج القناة واستخدمه لقراءة مشروعات Jira الداخلية. أصلحت Snowflake سير العمل في يوم الإبلاغ ودورت الرمز في اليوم التالي.

هل كان هذا هجوماً حقيقياً؟

كان هجوماً مصرحاً به. عمل Red Agent تحت برنامج مكافآت الثغرات HackerOne لدى Snowflake، وأفصحت Wiz فوراً، وأكدت سجلات التدقيق لدى Snowflake أن Wiz كانت الفاعل الوحيد خلال الأيام الخمسة التي ظلت فيها الثغرة حية. لم يُصل إلى بيانات العملاء. لكن التقنية تعمل بالطريقة نفسها لوكيل غير مصرح به، وهذه هي النقطة.

ماذا يعني هذا لوكلاء الأمن بالذكاء الاصطناعي؟

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

الخلاصة

أزل دراما Copilot، وتبقى حقيقتان. راجع ماسح أمني تقليدي ومكلف هذه الشفرة ومررها. وقرأ وكيل مستقل الشفرة نفسها وفهمها بما يكفي لتحويلها إلى سلاح، وصحح أخطاءه بنفسه على الطريق. الفجوة التي استمرت خمسة أيام بين «دُمجت» و«استغلتها آلة» هي الرقم الذي ينبغي لفرق الأمن أن تنظر إليه، لأن الوكلاء الهجوميين أصبحوا منتجاً لا عرضاً بحثياً، وهم لا يأخذون عطلة نهاية الأسبوع. سيُنسى سطر نسبة Copilot إلى التأليف الشهر المقبل. القدرة لن تُنسى.

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

المصادر

• Wiz Research، Gal Nagli، «Wiz Red Agent يجد طريقه إلى Jira الداخلي لدى Snowflake عبر ثغرة في طلب سحب ساعد فيه GitHub Copilot»: https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug (نُشر في 2026-08-17، وحُدث في 2026-08-17 19:57 UTC، واستُرجع في 2026-08-29)

• Wiz، «تقديم Wiz Red Agent، مهاجم مدعوم بالذكاء الاصطناعي»: https://www.wiz.io/blog/introducing-the-wiz-red-agent (نُشر في 2026-03-23، واستُرجع في 2026-08-29)

• Cybersecurity News، «وكيل ذكاء اصطناعي يخترق سير عمل Snowflake على GitHub»: https://cybersecuritynews.com/ai-agent-hacks-snowflake-github-workflow/ (نُشر في 2026-08-20، واستُرجع في 2026-08-29)

• CSO Online، «ثغرة Snowflake تتجاوز فحوص الذكاء الاصطناعي ويستغلها ذكاء اصطناعي آخر»: https://www.csoonline.com/article/4211501/snowflake-flaw-slips-past-ai-checks-gets-exploited-by-another-ai.html (نُشر في 2026-08-19، واستُرجع في 2026-08-29)

• Infosecurity Magazine، «وكيل Wiz للذكاء الاصطناعي يجد ثغرة حرجة في مستودع Snowflake على GitHub»: https://www.infosecurity-magazine.com/news/wiz-ai-agent-finds-snowflake/ (نُشر في 2026-08-18، واستُرجع في 2026-08-29)

• daily.dev، نقلاً عن The Next Web، «GitHub ترفض ادعاء Wiz بأن Copilot Autofix كتب ثغرة Snowflake»: https://daily.dev/posts/github-disputes-wiz-s-claim-that-copilot-autofix-wrote-a-snowflake-flaw-ybruxnh95 (نُشر في 2026-08-18، واستُرجع في 2026-08-29)

• مستودع snowflakedb/snowflake-connector-net: https://github.com/snowflakedb/snowflake-connector-net (استُرجع في 2026-08-29)