هجوم سلاسل الإمداد يضرب بيئة Packagist ببرمجيات خبيثة عبر GitHub

مقدمة تحليلية

في الثالث والعشرين من مايو 2026، كشف باحثو الأمن عن حملة هجمات خبيثة منسقة استهدفت مستودع البرمجيات الشهير Packagist، مما أثر بشكل مباشر على ثمانية حزم برمجية تستخدم على نطاق واسع في بيئة تطوير PHP وComposer. هذه الهجمات لا تمثل مجرد اختراق تقليدي لحزم برمجية، بل تكشف عن نمط هجومي هجين ومتطور عابر للأنظمة البيئية Cross-Ecosystem، حيث استغل المهاجمون التداخل الشائع بين لغة PHP وأدوات بناء واجهات المستخدم المعتمدة على لغة JavaScript لتمرير حمولات برمجية خبيثة تستهدف أنظمة التشغيل Linux.

وفقاً للبيانات الصادرة عن شركة الأمن البرمجي Socket، فإن المهاجمين تجنبوا بذكاء وضع أي شيفرات مشبوهة داخل ملف الإعداد الرئيسي Composer.json الخاص ببيئة PHP. بدلاً من ذلك، قاموا بدس الشيفرة الخبيثة في ملف package.json المخصص لبيئة Node.js وJavaScript، مستهدفين بشكل مباشر المطورين وفرق العمل التي تشحن أدوات بناء واجهات جافا سكريبت مدمجة مع كود PHP الخلفي. هذه المناورة الذكية سمحت للهجوم بالمرور دون أن تكتشفه أدوات الفحص التقليدية التي تركز فقط على مراجعة ملفات التكوين الخاصة ببيئة التطوير الرئيسية للمشروع.

التحليل التقني

يرتكز الهجوم على آلية متسلسلة تبدأ بمجرد تثبيت الحزم المصابة، حيث يتم تفعيل خطاف التثبيت اللاحق postinstall script المدرج داخل ملف التكوين package.json. بمجرد تشغيل هذا الخطاف، يقوم الكود الخبيث بسلسلة من العمليات الآلية المعقدة لتجاوز عناصر الأمان المحلية وتثبيت البرمجية الخبيثة في عمق نظام التشغيل Linux المستضيف.

تتضمن الخطوات التقنية الدقيقة للهجوم ما يلي:

• تخطي التحقق من أمان الشبكة: يقوم البرنامج النصي الخبيث بتعطيل التحقق من شهادات الأمان SSL/TLS verification لتجنب حدوث أي أخطاء برمجية قد تثير شك المطورين أثناء عملية الاتصال بخادم التحميل الخارجي.
• تحميل برمجية Linux ثنائية: يقوم الكود بالاتصال برابط خارجي مستضاف على منصة GitHub Releases وتحديداً على المستودع التابع للمستخدم المسمى parikhpreyash4/systemd-network-helper-aa5c751f لتحميل ملف ثنائي مجمع لنظام Linux.
• تخزين الحمولة وإخفاؤها: يتم حفظ الملف الثنائي المحمل داخل المسار المؤقت /tmp/.sshd لتمويه العملية وجعلها تبدو كجزء من خادم SSH الآمن في النظام.
• تعديل الصلاحيات والتشغيل الخلفي: يتم استخدام أمر chmod لمنح صلاحيات التنفيذ الكاملة لجميع المستخدمين على الملف المحمل، ومن ثم تشغيله في الخلفية background كعملية مستقلة تحمل اسم gvfsd-network للتمويه، وهو اسم يحاكي خدمة GNOME Virtual File System المخصصة لإدارة اتصالات الشبكة.

وقد شملت هذه الحملة التخريبية ثمانية حزم محددة بإصداراتها التالية:

• moritz-sauer-13/silverstripe-cms-theme (إصدار dev-master)
• crosiersource/crosierlib-base (إصدار dev-master)
• devdojo/wave (إصدار dev-main)
• devdojo/genesis (إصدار dev-main)
• katanaui/katana (إصدار dev-main)
• elitedevsquad/sidecar-laravel (إصدار 3.x-dev)
• r2luna/brain (إصدار dev-main)
• baskarcm/tzi-chat-ui (إصدار dev-main)

التحقيقات الأمنية الموسعة كشفت أن هذا الهجوم لا يقتصر على الحزم الثمانية فحسب، بل تم العثور على مراجع لنفس الحمولة البرمجية الخبيثة موزعة في أكثر من 777 ملفاً على منصة GitHub. في حالتين موثقتين على الأقل، تم إدخال الشيفرة الخبيثة مباشرة في ملفات سير العمل الخاصة بـ GitHub Workflows (وتحديداً في ملفات deploy_coding.yml و ci.yml)، مما يعني أن المهاجم كان يستهدف تشغيل البرمجية الخبيثة أثناء عمليات البناء والإنتاج الآلي CI/CD وليس فقط على الأجهزة المحلية للمطورين.

السياق وتأثير السوق

يعيد هذا الحادث تسليط الضوء على الضعف الهيكلي في سلاسل إمداد البرمجيات المفتوحة المصدر Open Source Software Supply Chain. في السنوات الأخيرة، ركزت هجمات سلاسل الإمداد على تقنيات مثل خداع الأسماء Typosquatting أو اختراق حسابات المطورين مباشرة. ومع ذلك، فإن الهجوم الحالي يوضح تحولاً نوعياً نحو استغلال المشاريع متعددة التقنيات Polyglot Projects التي تستخدم لغات برمجية وبيئات تشغيل متعددة في نفس الوقت.

أصبح من المعتاد جداً أن تشتمل تطبيقات PHP الحديثة (مثل إطار عمل Laravel أو Drupal) على واجهات مستخدم تُبنى باستخدام React أو Vue.js، مما يتطلب وجود ملفات package.json و composer.json جنباً إلى جنب. هذا التداخل يخلق نقطة عمياء قاتلة؛ حيث تفترض فرق هندسة الأمان والمطورون أن فحص تبعيات PHP كافٍ لحماية المشروع، غافلين عن أن بيئة Node.js المصاحبة قد تحتوي على ثغرات تؤدي إلى تنفيذ كود عشوائي عن بعد RCE على خوادم التطوير أو خوادم الإنتاج والـ CI/CD.

رؤية Glitch4Techs

في منصة Glitch4Techs، نرى أن هذا الهجوم يمثل جرس إنذار حرج لجميع مهندسي DevOps ومسؤولي الأمن السيبراني. إن الحقيقة المقلقة هي أنه حتى في حال عدم تفعيل الحمولة الثنائية النهائية للملف (نظراً لقيام GitHub بحذف الحساب المرتبط بالمستودع المخترق لاحقاً)، فإن مجرد محاولة تشغيل خطافات التثبيت وتعديل الصلاحيات دون فحص يمثل تهديداً وجودياً لأمن البنية التحتية البرمجية.

تتمثل المشكلة الأساسية في غياب جدران الحماية بين بيئات التشغيل أثناء مرحلة البناء والتركيب. نوصي باتخاذ الإجراءات الصارمة التالية للحد من هذه المخاطر:

• تعطيل نصوص التثبيت الآلية: يجب تكوين مديري الحزم لمنع تشغيل نصوص التثبيت الآلية افتراضياً، باستخدام خيار --ignore-scripts عند تشغيل npm install أو yarn install.
• مراقبة بيئة التطوير والـ CI/CD: عزل خوادم البناء الآلي بيئياً ومنعها من إجراء اتصالات شبكية خارجية غير مصرح بها أثناء فترات بناء الحزم.
• الفحص الشامل لجميع اللغات: عدم الاعتماد على أدوات فحص مخصصة للغة برمجية واحدة، بل يجب استخدام أدوات تحليل أمان قادرة على كشف التبعيات والمخاطر في جميع بيئات المشروع المشتركة.

إن الثقة العمياء في الحزم البرمجية والاعتماد على سمعة المنصات المستضيفة مثل Packagist أو GitHub Releases لم يعد خياراً آمناً، ويجب أن تتحول استراتيجية الأمان فوراً إلى نموذج صفر ثقة Zero Trust في كل خطوة من خطوات عملية التطوير ونشر البرمجيات.