كشفت حملة قرصنة جديدة تستهدف مستودعات البرمجيات مفتوحة المصدر على منصة GitHub عن وجود سلسلة هجمات مبتكرة تستغل تحديثات إعدادات بناء البرمجيات (CI) المزيفة لسرقة بيانات حساسة. وقد بدأت هذه الحملة في مارس 2026، حيث يستغل المهاجمون نقطة ضعف محددة في “GitHub Actions” للوصول إلى رموز الوصول وبيانات الاعتماد الخاصة بالمطورين.
ظهرت الحملة لأول مرة في 11 مارس 2026، عندما بدأ أحد المهاجمين، مستخدماً حساب GitHub باسم “testedbefore”، في تقديم طلبات سحب (pull requests) خبيثة إلى المستودعات الصغيرة. وعلى مدار الأسابيع التالية، تنقل المهاجم بين ستة حسابات مختلفة على GitHub، وقام بإرسال أكثر من 500 طلب سحب مزيف. وكان عنوان هذه الطلبات موحداً وهو “ci: update build configuration”، مما يجعل من الصعب على المطورين اكتشاف الخطر المضمن.
استغلال ثغرات GitHub Actions
تصاعدت وتيرة الحملة بشكل كبير في 2 أبريل 2026، بعد أن لفت الباحث الأمني تشارلي إريكسن الانتباه إليها، حيث قدم حساب “ezmtebo” أكثر من 475 طلب سحب خبيث خلال 26 ساعة فقط. وقد تمكن محللو Wiz Research من تتبع الحملة بالكامل قبل ذلك بثلاثة أسابيع، محددين ست موجات نشاط منفصلة قام بها نفس المهاجم.
قام باحثون آخرون بتأكيد اختراق ناجح لحزمتين على الأقل من حزم npm وهما “@codfish/eslint-config” و “@codfish/actions”، وذلك عبر 106 إصدارات مختلفة لهذه الحزم. تمت سرقة مفاتيح AWS ورموز API الخاصة بـ Cloudflare وبيانات اعتماد Netlify بشكل مؤكد. ومع ذلك، تمكنت بعض الجهات المستهدفة مثل Sentry وOpenSearch وNixOS من منع هذه الهجمات من خلال آليات صارمة للموافقة على المساهمات.
آلية الهجوم المبتكرة
ما يميز هذه الحملة هو الاستخدام المتعمد لأدوات مؤتمتة مدعومة بالذكاء الاصطناعي للتكيف مع كل هدف. يقوم المهاجم بنسخ المستودعات المستهدفة، وتحليل التقنيات المستخدمة فيها، ثم إدراج الحمولة الخبيثة في الملف المناسب لكل لغة برمجة. على سبيل المثال، يتم وضعها في ملفات اختبار Go لمشاريع Go، وملف “conftest.py” لمشاريع Python، ونصوص “package.json” لمشاريع Node.js.
هذا المستوى من التكيف لم يعد يتطلب مهارات تقنية عميقة، بل هو نتاج لأدوات مدفوعة بالذكاء الاصطناعي تسمح حتى للمهاجمين ذوي الكفاءة المنخفضة بشن حملات واسعة النطاق على سلسلة توريد البرمجيات بسرعة فائقة. على الرغم من انتشارها الواسع، ظلت نسبة النجاح الإجمالية للحملة أقل من 10% عبر أكثر من 450 محاولة استغلال تم تحليلها.
كانت معظم النجاحات الموثقة ضد مشاريع هواة صغيرة، مما أدى إلى كشف رموز GitHub Workflow مؤقتة فقط. ومع ذلك، مع ما يزيد عن 500 محاولة إجمالية، يمكن أن تؤدي نسبة 10% حتى إلى عشرات الاختراقات الحقيقية، وكان المهاجم يقوم باستمرار بالتعلم وتحسين الحمولة وزيادة قدرته على التهرب مع كل موجة جديدة. إن فهم آلية عمل هذه الثغرة يساعد المؤسسات في تعزيز أمنها.
فهم آلية عمل هجمات GitHub
تعتمد الحملة على استغلال مشغل “pull_request_target” في GitHub Actions. على عكس المشغل القياسي “pull_request”، يعمل هذا المشغل بالكامل في سياق المستودع الأساسي وليس المستودع المنسوخ، مما يمنح وصولاً كاملاً إلى أسرار المستودع حتى عندما يأتي طلب السحب من حساب خارجي غير موثوق به.
تكون المستودعات التي تفشل في تقييد هذا المشغل على المساهمين المعتمدين فقط معرضة بشكل مباشر لهذا النوع من الهجمات. عندما يعمل سير العمل الضعيف على طلب سحب خبيث، تبدأ الحمولة على الفور في عملية من خمس مراحل. أولاً، تستخرج “GITHUB_TOKEN” من تكوين git، ثم تضغطها، وتكتب مخرجات مشفرة بصيغة base64 إلى سجلات سير العمل ليتم استرجاعها لاحقاً من قبل المهاجم.
تستخدم المرحلة الثانية هذا الرمز المسروق لاستدعاء واجهة برمجة تطبيقات GitHub، لتحديد أسماء الأسرار وبيئات النشر وملفات سير العمل. وفي الوقت نفسه، يقوم بفحص نقاط نهاية بيانات التعريف السحابية بحثًا عن بيانات اعتماد AWS و Azure و Google Cloud. بعد ذلك، تقوم خدمة خلفية بمراقبة نظام ملفات Linux “/proc” كل ثانيتين لمدة عشر دقائق، لالتقاط أي أسرار يتم تحميلها بواسطة خطوات لاحقة في سير العمل، وترسل البيانات الملتقطة مباشرة إلى تعليقات طلب السحب، حيث تبقى حتى بعد مسح سجلات سير العمل.
يجب على المؤسسات التدقيق فورًا في مستودعات GitHub الخاصة بها بحثًا عن مؤشرات محددة على الاختراق، مثل الفروع التي تطابق النمط “prt-scan-[12-character-hex]”، وطلبات السحب بعنوان “ci: update build configuration”، وعلامات سجل سير العمل مثل “==PRT_EXFIL_START_[nonce]==”. يجب على المسؤولين تقييد استخدام “pull_request_target” للمساهمين المعتمدين فقط، وتطبيق بوابات موافقة صارمة للمساهمين لأول مرة، وتطبيق شروط مشغل سير العمل المقيدة بالفاعل أو المسار.
يجب تدوير أي بيانات اعتماد مكشوفة، بما في ذلك مفاتيح AWS ورموز NPM ورموز API السحابية، على الفور. ويعد أمان سلسلة توريد البرمجيات، وخاصة في بيئات تطوير مثل GitHub، أمراً حيوياً لحماية البيانات الحساسة.

