كيف اكتشف Red Agent ثغرة في GitHub Actions مرتبطة بـ Copilot Autofix واستغلها

لم تكن الحادثة ثغرة في الشيفرة التشغيلية لموصل Snowflake for .NET الذي يصل إلى العملاء، بل خللًا في سير عمل GitHub Actions داخل المستودع العام snowflakedb/snowflake-connector-net. فقد وضع تغيير دُمج في 18 يونيو 2026 عنوان Issue يسيطر عليه المستخدم داخل أمر Shell، قبل أن يكتشف Wiz Red Agent الثغرة ويختبرها بعد خمسة أيام ضمن عملية إفصاح أمنية مصرح بها عبر HackerOne.

التغيير الذي فتح باب الحقن

كان الخلل في الملف .github/workflows/jira_issue.yml، وهو سير عمل يُشغّل عند فتح أي Issue في المستودع. وفي طلب السحب رقم PR #1218، المعنون «SNOW-2069227: Update Jira workflows»، استُبدل أسلوب أكثر أمانًا كان يمرر عنوان Issue عبر متغير بيئة ويستخدم jq لبناء JSON، بأسلوب يدرج

${{ github.event.issue.title }}

تكمن المشكلة في توقيت المعالجة: توسّع GitHub هذا التعبير قبل أن ينفذ Shell الأمر. لذلك كان بإمكان عنوان يحتوي على علامة اقتباس مفردة أن يغلق النص المقصود، ثم يضيف أوامر Shell يختارها المهاجم. أما تنظيف القيمة لاحقًا باستخدام sed فلم يكن قادرًا على التراجع عن تفسير Shell الذي حدث مسبقًا.

كما أن تشغيل سير العمل عبر

issues: opened

ويحمل التعديل سجل ائتمان بعبارة «Copilot Autofix powered by AI» بوصفه شريكًا في التأليف، كما أن المراجعة المدعومة بالذكاء الاصطناعي لم تنبّه إلى المشكلة. لكن الأدلة المتاحة لا تثبت ما إذا كان Copilot قد أنشأ التغيير غير الآمن أو راجع تغييرًا كتبه إنسان من دون اكتشاف الحقن. والاستنتاج الأدق هو أن Copilot ارتبط بالتغيير وأخفق في اكتشاف الثغرة، لا أن تأليف النموذج للتعديل مثبت بصورة قاطعة.

كيف عثر Red Agent على الثغرة؟

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

وفي 23 يونيو، أي بعد خمسة أيام من دمج التغيير، فتح الوكيل Issue مُصاغًا بعناية ضمن برنامج Snowflake للإفصاح عن الثغرات عبر HackerOne. أدى العنوان إلى كسر سلسلة Shell، ثم إلى إرسال بيانات اعتماد Jira إلى نقطة اتصال خارجية تُستخدم في إثبات المفهوم المصرح به.

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

ما الذي كشفه الاستغلال؟

كان سير العمل المخترق يملك إعدادات الوصول إلى Jira الداخلية في Snowflake، بما في ذلك عنوان Jira والبريد الإلكتروني للمستخدم ورمز API. ارتبط الرمز المستعاد بالحساب qa@snowflake.net، واستخدمته Wiz لتسجيل الدخول إلى بوابة Jira الداخلية وتقييم نطاق التعرض.

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

وكان الأصل المتأثر هو أتمتة CI/CD في المستودع، لا منتج الموصل نفسه. ولم يُبلّغ عن إصدار متأثر من Snowflake Connector for .NET، لأن الخلل كان في سير عمل GitHub Actions لا في الشيفرة التشغيلية للموصل.

استجابة Snowflake

أبلغت Wiz عن المشكلة في 23 يونيو، فعالجت Snowflake سير العمل في اليوم نفسه، ثم دوّرت بيانات اعتماد Jira المكشوفة في اليوم التالي.

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

ولم يُبلّغ عن وصول غير مصرح به من طرف ثالث، أو عن إسناد رقم CVE، أو عن تأثر إصدار من الموصل. وتحدد هذه النقاط نطاق الأثر المؤكد، لكنها لا تجعل تصميم سير العمل الأصلي آمنًا؛ إذ لا ينبغي أن يتحول عنوان Issue عام إلى جزء من أمر Shell داخل سير عمل يتعامل مع بيانات اعتماد داخلية.

الدرس الأوسع لأمن CI/CD

تتجاوز دلالة الحادثة Snowflake وCopilot. فعناوين Issues وطلبات السحب، وأسماء الفروع، والتعليقات، وأي قيم أخرى تأتي من تعبيرات GitHub، يجب التعامل معها كمدخلات عدائية كلما انتقلت إلى أمر Shell.

وتشمل الممارسات الأكثر أمانًا ما يلي:

• تمرير القيم غير الموثوقة عبر متغيرات البيئة بدل إدراجها مباشرة في نصوص run:.
• استخدام أدوات منظمة مثل jq لبناء JSON بدل تركيب سلاسل Shell يدويًا.
• وضع الاقتباس والتحقق من صحة البيانات عند حدود Shell.
• إبعاد بيانات الاعتماد عن الخطوات التي تعالج محتوى يسيطر عليه المهاجم كلما أمكن.
• مراجعة التغييرات الأمنية التي تنتجها أدوات الذكاء الاصطناعي بالصرامة نفسها المطبقة على الشيفرة التي يكتبها البشر.

تقدم هذه الواقعة مثالًا مكثفًا على تحدٍ أمني جديد: نظام ذكاء اصطناعي للمساعدة في البرمجة قد يفوّت تغييرًا خطيرًا في CI/CD، بينما يعثر وكيل هجومي مستقل على الخلل ويتحقق منه خلال أيام. تستطيع الأتمتة تسريع الإصلاح والاستغلال معًا، لكنها لا تغني عن المراجعة المستقلة.