كشفت شركة الأمن السيبراني Aikido Security عن حملة سرقة بيانات اعتماد استُخدمت فيها 4,837 حسابًا مخترقًا على GitHub لفحص عشرات الآلاف من المستودعات البرمجية، ثم زرع برمجية خبيثة داخل بيئات البناء الآلي لسرقة مفاتيح الوصول وأسرار الخدمات السحابية. وتحمل الحملة اسم wfx-loot، وبدأ رصد نشاطها في 10 نوفمبر 2026، وفق تحليل الشركة المنشور في 12 نوفمبر.
لا تعني الأرقام أن منصة GitHub نفسها تعرضت لاختراق في بنيتها التحتية؛ فالأسلوب اعتمد على استخدام بيانات دخول مسروقة لحسابات مطورين حقيقية، ثم استغلال صلاحيات الكتابة التي تمتلكها هذه الحسابات داخل المستودعات. وهذه نقطة مهمة لفهم الحادث: المهاجم لم يحتج إلى كسر حماية المنصة إذا كان يستطيع الدخول بهوية مستخدم موثوق.
كيف استُخدمت آلاف الحسابات المخترقة؟
بحسب Aikido، استخدم المهاجمون 4,837 حسابًا لفتح طلبات دمج Pull Requests في 61,764 مستودعًا. حملت الطلبات عنوانًا متكررًا هو docs: dependency audit notes، وجاءت من فرع باسم wfx-docs. لم يكن طلب الدمج نفسه هو الحمولة الخبيثة؛ بل كان اختبارًا لمعرفة ما إذا كان الحساب يستطيع تعديل المستودع المستهدف.
وصلت 10,431 من هذه الطلبات إلى مستودعات لا يملكها الحساب الذي فتحها، لكن صاحبه كان يستطيع الوصول إليها بصفته متعاونًا أو عضوًا في مؤسسة. وذكرت Aikido أن نحو 92% من الطلبات التي رصدتها ظلت مفتوحة وقت إعداد تقريرها، وهو ما يشير إلى أن عددًا كبيرًا من أصحاب المستودعات ربما لم ينتبهوا إلى النشاط غير المعتاد.
بعد التأكد من وجود صلاحية كتابة، انتقل المهاجم إلى زرع الحمولة في المستودع. ورصدت الشركة ثلاثة أساليب رئيسية: تعديل سير عمل قائم في GitHub Actions، أو إضافة سكربت يعمل عبر خطاف postinstall عند تثبيت حزم npm، أو إنشاء ملف Workflow مؤقت داخل فرع جديد. واستخدمت بعض التغييرات رسائل مثل ci: refresh build cache وchore: add ci helper لتبدو كأنها تعديلات صيانة عادية.
برمجية خبيثة تبحث عن أسرار المطورين
تتكون الحمولة، وفق التحليل المنشور، من سكربت Shell يبلغ حجمه نحو 1500 سطر. وهي لا تكتفي بسرقة رمز دخول واحد؛ بل تبحث في بيئة التشغيل عن مجموعة واسعة من البيانات التي قد تكون متاحة لعملية البناء الآلي. وتشمل الأهداف أسرار GitHub Actions ومتغيراته، ورمز GITHUB_TOKEN، ورموز OIDC، ومفاتيح الوصول إلى AWS وAzure وGoogle Cloud.
كما بحث السكربت عن ملفات إعداد Docker وKubernetes، ومفاتيح SSH وGPG، وبيانات npm وPyPI وTerraform وHashiCorp Vault، إضافة إلى ملفات البيئة الخاصة بالمشروعات وسجل الأوامر في الطرفية. وامتد نطاق البحث إلى مفاتيح خدمات الذكاء الاصطناعي وأدوات التطوير، بما فيها OpenAI وAnthropic وGemini وHugging Face وCursor وCopilot وCodex، إذا كانت بياناتها موجودة في البيئة التي وصل إليها السكربت.
وهذا يوضح لماذا لا يقتصر أثر الحملة على مستودع الشيفرة وحده. فقد تحتوي بيئة CI/CD على مفاتيح نشر التطبيق، أو صلاحيات دخول إلى خوادم الإنتاج، أو بيانات اعتماد لخدمات خارجية. وإذا تمكن المهاجم من قراءة هذه الأسرار، فقد ينتقل من مشروع برمجي واحد إلى حسابات سحابية أو أدوات يستخدمها فريق التطوير بأكمله.
محاولات لإبقاء الوصول حتى بعد تغيير المفاتيح
لم تتوقف الحمولة عند جمع البيانات وإرسالها. يشرح تقرير Aikido أنها حاولت استخدام الرموز المسروقة للحصول على جلسات وصول سحابية، ثم توسيع الصلاحيات وإنشاء وسائل دخول تستمر بعد تدوير بعض المفاتيح. ومن الأمثلة التي رصدها التقرير تعديل سياسة الثقة لبعض أدوار AWS لتسمح بمبدأ وصول واسع، وإنشاء بيانات اعتماد هوية اتحادية جديدة في تطبيقات Azure بأسماء تبدأ بالبادئة wfx-ci-.
هذه التفاصيل تجعل الاستجابة للحادث أكثر تعقيدًا من حذف السكربت أو تغيير مفتاح API واحد. فإذا أضاف المهاجم وسيلة مصادقة جديدة إلى حساب سحابي، فقد يظل قادرًا على الدخول حتى بعد إبطال الرمز الأصلي. لذلك أوصت الشركة المتضررين بمراجعة إعدادات الثقة والهويات الاتحادية، إلى جانب تدوير جميع الأسرار التي كان يمكن لسير العمل الوصول إليها.
إخفاء آثار التنفيذ خلال وقت قصير
من أكثر جوانب الحملة إثارة للقلق أن المهاجمين حاولوا إزالة آثار التعديل بعد تشغيل الحمولة. يذكر التقرير أن التغييرات كانت تُعكس بسرعة، وقد تُحذف سجلات تشغيل Workflow نفسها خلال نحو دقيقة. وفي بعض الحالات، قد يكون غياب رقم تشغيل متسلسل من سجل GitHub Actions مؤشرًا يستحق التحقيق، حتى إذا لم يعد الملف الخبيث ظاهرًا في النسخة الحالية من المستودع.
وتشير Aikido إلى أنها رصدت أدلة على تشغيل الحمولة وتسريب بيانات من 1,806 مستودعات على الأقل في جزء من تقريرها، بينما يذكر ملخص التقرير رقم 1,835 مستودعًا. لذلك من الأدق التعامل مع الرقمين بوصفهما تقديرين وردا في التقرير نفسه، لا تقديم أحدهما باعتباره حصيلة نهائية محسومة. كما أن عدد المستودعات التي تلقت طلبات فحص لا يساوي عدد المستودعات التي شغّلت البرمجية الخبيثة بالفعل.
هل امتد الهجوم إلى حزم برمجية منشورة؟
رصدت Aikido وصول آثار الحملة إلى حزمة PHP منشورة عبر Packagist، وإلى إصدارات محددة من وحدة Go، نتيجة آليات النشر الآلي المرتبطة ببعض المستودعات. ومن بين الإصدارات التي ذكرتها الشركة digitalelvis/neuronai-studio بالإصدار 3.14.3، وgithub.com/onuragtas/docker-env بالإصدارين v1.0.278 وv1.0.280.
لكن الشركة تميز بين وجود ملف Workflow خبيث داخل مستودع أو إصدار، وبين تشغيله عند استخدام الحزمة. وأوضحت أن الحمولة الموجودة في إصدارات Go المذكورة كانت داخل ملف GitHub Actions فقط، وأن بناء مشروع Go لا يشغّل ملفات Workflow. لذلك لا يصح افتراض أن كل من نزّل هذه الإصدارات تعرض للاختراق بالطريقة نفسها؛ أما الحزمة المحددة على Packagist فتتطلب التعامل معها بحذر أكبر وفق تعليمات الشركة.
ما الذي ينبغي على المطورين مراجعته؟
إذا كان فريقك يستخدم GitHub في إدارة الشيفرة أو تشغيل عمليات النشر، فالمراجعة يجب ألا تقتصر على المستودعات التي تملكها مباشرة؛ بل تشمل كل مشروع تملك حسابات الفريق صلاحية الكتابة فيه، بما في ذلك مستودعات العملاء والمؤسسات التي يعمل معها المطورون.
- ابحث عن فرع باسم
wfx-docsأو طلب دمج بعنوانdocs: dependency audit notesمنذ 10 نوفمبر 2026. - راجع رسائل الالتزام غير المعتادة، ومنها
ci: refresh build cacheوchore: add ci helperوchore: add dependency audit workflow. - افحص سجل GitHub Actions بحثًا عن تشغيل مفقود أو فجوة غير مفسرة في أرقام التشغيل قرب وقت التعديلات.
- إذا ظهرت مؤشرات تشغيل الحمولة، ألغِ الرموز والجلسات المتأثرة ودوّر كل أسرار المستودع والمؤسسة التي كان بإمكان Workflow قراءتها.
- راجع سياسات الثقة في AWS وبيانات الاعتماد الاتحادية في Azure، ولا تكتفِ بتغيير المفاتيح القديمة.
- قلل صلاحيات رموز التشغيل إلى الحد الضروري، وافصل أسرار الإنتاج عن المهام التي لا تحتاج إليها.
يمكن الرجوع إلى تحليل Aikido Security الأصلي لحملة wfx-loot، وإلى وثائق GitHub الرسمية حول انتهاء صلاحية الرموز وإبطالها. وتوثق GitHub في إرشاداتها الرسمية طرق انتهاء صلاحية الرموز وإبطالها، كما توفر واجهة لإبطال أنواع من بيانات الاعتماد المكشوفة، بما فيها رموز الوصول الشخصية ورموز تطبيقات OAuth وGitHub Apps. وتوضح الوثائق أن الرمز الذي أُلغي لا يمكن استعادته، وأن التطبيقات والمهام التي تعتمد عليه ستحتاج إلى إنشاء بيانات اعتماد جديدة وتحديث إعداداتها.
وتزداد أهمية حماية الأسرار مع توسع استخدام وكلاء الذكاء الاصطناعي وأدوات البرمجة التي تتصل بالمستودعات والخدمات الخارجية. وقد تناولنا في خبر إطلاق NVIDIA منصة Open Agent Safety لحماية وكلاء الذكاء الاصطناعي كيف يمكن فرض حدود مستقلة على وصول الوكلاء إلى الملفات والشبكات وبيانات الاعتماد؛ وهي زاوية مرتبطة بالمشكلة الأوسع نفسها، أي أن امتلاك الأداة لصلاحية الوصول لا يعني ضرورة منحها وصولًا غير محدود.
حتى وقت نشر تقرير Aikido، لم يكن محور الحادث ثغرة برمجية معلنة في GitHub Actions، بل إساءة استخدام حسابات مخترقة وصلاحياتها المشروعة. وهذا فارق أساسي عند تقييم المخاطر: تحديث منصة GitHub وحده لا يعالج حسابًا مسروقًا أو رمز وصول لا يزال صالحًا، كما أن إزالة التعديل الخبيث لا تضمن إبطال الأسرار التي ربما خرجت بالفعل من بيئة البناء.
لا يسمح بنقل هذا المحتوى من سوالف دون الاشارة برابط مباشر
