اختراق حزم Laravel-Lang البرمجية لنشر برمجية خبيثة تسرق البيانات

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

في 22 و23 مايو 2026، رصد الباحثون الأمنيون في منصتي Socket وStepSecurity هجوماً خطيراً استهدف سلاسل التوريد البرمجية الخاصة بمنظمة Laravel-Lang الشهيرة على منصة GitHub. الهجوم لم يعتمد على تعديل الكود المصدري البرمجي المباشر للمشاريع، بل استغل تكتيكاً خبيثاً ومبتكراً تمثل في إعادة كتابة وسوم Git (Git Tags) لأكثر من 700 إصدار في وقت قياسي لإجبار خوادم التطبيقات على تنزيل برمجية سرقة معلومات عابرة للمنصات. يمثل هذا الاختراق نقطة تحول مقلقة في كيفية استهداف البنية التحتية لتطوير الويب، حيث يستهدف آلاف التطبيقات التي تعتمد على إطار العمل الشهير Laravel ومكوناته اللغوية المساعدة دون أن يثير أي ريب لدى أنظمة التدقيق البرمجي التقليدية.

الحزم البرمجية التي تم تأكيد إصابتها تشمل حزماً أساسية هي laravel-lang/lang وlaravel-lang/http-statuses وlaravel-lang/attributes وlaravel-lang/actions. إن خطورة الهجوم تكمن في قدرته على التنفيذ التلقائي الفوري بمجرد إقلاع أي تطبيق يعتمد على هذه الحزم المصابة، مما يعني أن المطورين والشركات الذين يستخدمون هذه الأدوات أصبحوا ضحايا فوريين دون الحاجة لأي تفاعل برمي مباشر أو استدعاء يدوي للدوال الخبيثة.

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

تعتمد آلية الهجوم على التلاعب بملف الإعدادات الخاص بإدارة حزم PHP الشهير Composer وتحديداً خريطة التحميل التلقائي المعروفة باسم autoload.files داخل ملف composer.json لكل حزمة من الحزم المخترقة. تم دمج ملف خبيث مخصص يحمل الاسم src/helpers.php ضمن هذه الخريطة، وهو ما يؤدي تلقائياً إلى تحميله بمجرد استدعاء الملف الأساسي vendor/autoload.php الذي يعتمد عليه أي تطبيق PHP حديث كإطارات العمل Laravel وSymfony ومكتبة الاختبارات الشهيرة PHPUnit.

بمجرد أن يبدأ خادم التطبيق بالعمل وتنزيل الحزم، تنشط البرمجية الخبيثة وتمر عبر عدة مراحل تقنية دقيقة:

• توليد معرف فريد (Fingerprinting): تقوم البرمجية بتوليد معرف فريد لكل خادم مستهدف عبر دمج مسار المجلد البرمجي وبنية نظام التشغيل (Architecture) ومعرف inode الخاص بملفات النظام، ثم تشفير هذه البيانات مجتمعة باستخدام خوارزمية MD5. يهدف هذا الإجراء لمنع تكرار تشغيل البرمجية الخبيثة على نفس الخادم وتجنب الكشف بواسطة أنظمة المراقبة الأمنية.
• الاتصال بخادم التحكم والسيطرة (C2): تقوم البرمجية بالاتصال بالخادم الخارجي flipboxstudio[.]info لتنزيل الحمولة البرمجية النهائية المخصصة لنظام تشغيل الضحية.
• الاستهداف عابر المنصات: تحدد البرمجية نظام التشغيل تلقائياً؛ فإذا كان الخادم يعمل بنظام Windows، يتم تشغيل سكربت Visual Basic Script خبيث باستخدام الأداة cscript. أما على أنظمة Linux وmacOS، فيتم تشغيل الحمولة مباشرة باستخدام دالة exec() المدمجة في PHP.

الحمولة النهائية المكتشفة عبارة عن ملف PHP ضخم يحتوي على حوالي 5,900 سطر برمجي، مقسم إلى 15 وحدة برمجية متخصصة ومصممة بدقة متناهية لجمع باقة واسعة من البيانات الحساسة للغاية من الخادم المصاب، والتي تشمل:

• بيانات الهوية وصلاحيات الوصول السحابية (IAM Roles) واستعلام خوادم البيانات الوصفية للمزودين السحابيين مثل AWS وGoogle Cloud وMicrosoft Azure.
• الرموز الأمنية وملفات التكوين لمنصات الاستضافة وKubernetes وHelm وDigitalOcean وHeroku وVercel وNetlify وRailway وFly.io وحاويات Docker وملفات docker-compose.yml.
• بيانات خوادم التطوير والدمج المستمر (CI/CD) مثل Jenkins وGitLab Runners وGitHub Actions وCircleCI وTravisCI وArgoCD.
• العبارات المفتاحية (Seed Phrases) والملفات المرتبطة بمحافظ العملات الرقمية المحلية أو المدمجة كإضافات في المتصفحات مثل MetaMask وTrezor وLedger Live وPhantom وغيرها.
• بيانات المتصفحات وسجلات التصفح وكلمات المرور المخزنة في متصفحات Chrome وEdge وFirefox وBrave وOpera، حيث يتم استخدام ملف تنفيذي مدمج مشفر بصيغة Base64 لتجاوز نظام حماية التشفير المعتمد على التطبيقات الخاص بجوجل كروم (App-Bound Encryption).
• ملفات التكوين الحساسة للغاية مثل مفاتيح الاتصال المشفرة SSH، وملفات البيئة .env وwp-config.php ومتغيرات البيئة النشطة في ذاكرة PHP.

بعد إتمام جمع كافة البيانات، تقوم البرمجية الخبيثة بتشغيل خوارزمية AES-256 لتشفير الحصيلة بالكامل وإرسالها إلى مسار التجميع flipboxstudio[.]info/exfil، تليها عملية تدمير ذاتي وحذف فوري لكافة الملفات الخبيثة من القرص الصلب لتقليل الأدلة الجنائية وتفادي كشف الهجوم.

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

يعيد هذا الحادث الخطير تسليط الضوء على الضعف الكامن والهشاشة المستمرة في سلاسل توريد البرمجيات مفتوحة المصدر (Software Supply Chain Security). إن اختيار المهاجمين لعدم العبث بالرمز المصدري الأساسي ومحاولة تمريره عبر طلبات السحب (Pull Requests) التي تخضع لمراجعات برمجية دقيقة، واللجوء بدلاً من ذلك إلى إعادة كتابة تاريخ إصدارات Git بالكامل، يوضح نضجاً كبيراً وتكتيكاً متقدماً لتجاوز أدوات الكشف التقليدية.

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

رؤية Glitch4Techs

يرى الخبراء في Glitch4Techs أن هذه العملية الأمنية تؤكد أن نماذج الثقة العمياء بالتحديثات التلقائية للمكتبات البرمجية أصبحت خطراً داهماً يهدد استمرارية الأعمال. لا يجب على المطورين الاكتفاء بتنزيل الحزم دون التحقق من توقيعاتها الرقمية. من الضروري جداً البدء فوراً في قفل الإصدارات عبر ملفات التكوين الصارمة مثل composer.lock، وتطبيق ممارسات التحقق من التواقيع المشفرة لوسوم Git (Signed Commits) لضمان أن التحديثات صادرة من المطورين الفعليين المعتمدين وليس من حسابات آلية مخترقة.

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