اختراق حزم Laravel Lang لنشر برمجيات خبيثة تسرق بيانات المطورين
فريق جلتشمنذ 7 دقائق0 مشاهدة5 دقائق

"تعرضت حزم Laravel Lang لاختراق سلاسل التوريد عبر التلاعب بعلامات GitHub البرمجية. استهدف الهجوم سرقة المفاتيح السحابية وبيانات المطورين عبر برمجيات خبيثة متطورة."
مقدمة تحليلية
شهد مجتمع مطوري الويب صدمة أمنية في الثالث والعشرين من مايو 2026 مع الكشف عن هجوم سلاسل توريد معقد استهدف حزم التوطين والترجمة الشهيرة لـ Laravel Lang. تمكن المهاجمون من استغلال آلية إدارة الإصدارات والعلامات على منصة GitHub لتوزيع برمجيات خبيثة مخصصة لسرقة البيانات الاعتمادية والمفاتيح الحساسة. الهجوم لم يستهدف نواة إطار العمل الشهير Laravel نفسه، بل ركّز على حزم ترجمة الطرف الثالث التابعة لمنظمة Laravel Lang التي يعتمد عليها آلاف المطورين حول العالم لبناء تطبيقاتهم متعددة اللغات. أشارت التقارير الأمنية الصادرة عن شركات أمن المعلومات StepSecurity وAikido Security وSocket إلى أن هذا الاختراق تميز بأسلوب فني غير تقليدي وجريء. فبدلاً من نشر إصدارات خبيثة جديدة تجذب الانتباه، قام المهاجمون بإعادة كتابة العلامات البرمجية التاريخية GitHub tags عبر مستودعات المنظمة وتوجيهها إلى تفرعات مخصصة forks تحتوي على الكود الخبيث. أدى هذا التلاعب إلى حقن البرمجيات الضارة في صمت داخل بيئات التطوير والإنتاج التي تستخدم أداة إدارة الحزم Composer لتثبيت وتحديث هذه المكتبات البرمجية. تكمن خطورة الهجوم في اتساع رقعة التأثير ومستوى تعقيد البرمجية المستخدمة؛ حيث تشير البيانات الأمنية إلى تضرر ما يتراوح بين 233 إلى ما يقرب من 700 إصدار تاريخي عبر مستودعات رئيسية تشمل laravel-lang/lang وlaravel-lang/http-statuses وlaravel-lang/attributes وربما laravel-lang/actions. هذا الأسلوب يضعف ثقة المطورين في آليات التحقق التقليدية ويفرض واقعاً أمنياً جديداً يتطلب تدقيقاً عميقاً في سلامة التوقيعات البرمجية قبل الاعتماد على حزم برمجية مفتوحة المصدر.التحليل التقني
استغل المهاجمون ثغرة بنيوية في كيفية تعامل بعض أدوات إدارة الحزم مع علامات التتبع في GitHub. في هذا الهجوم، لم يقم الفاعل الخبيث بتعديل الكود المصدري الأصلي في المستودع الرئيسي لـ Laravel Lang، بل استغل ميزة تتيح ربط علامات الإصدارات tags بالتزامات commits موجودة في مستودعات فرعية مشتقة forks تقع تحت سيطرة المهاجم. من خلال امتلاك وصول برمجي للمستودع عبر بيانات اعتماد مسروقة، تمت إعادة كتابة العلامات لتبدو كإصدارات رسمية لكنها تشير في الواقع إلى المستودع الفرعي الخبيث. عند قيام المطورين بتشغيل أمر التثبيت عبر Composer، يتم تحميل ملف composer.json المعدل الذي يحتوي على توجيه تلقائي لتحميل ملف جديد يحمل الاسم src/helpers.php مضافاً إلى قسم autoload. يعمل هذا الملف كأداة إسقاط dropper برمجية تقوم بالاتصال بخادم التحكم والسيطرة C2 المتمثل في النطاق flipboxstudio[.]info لتنزيل الحمولة البرمجية الخبيثة الأساسية. تتكون الحمولة الأساسية من برنامج نصي بلغة PHP يتضمن برمجية سرقة بيانات عابرة للمنصات تستهدف أنظمة التشغيل Windows وLinux وmacOS. تقوم هذه البرمجية بمسح البيئة المستهدفة لسرقة نطاق واسع من البيانات الحساسة عبر آليات دقيقة تشمل:- مفاتيح الخدمات السحابية ومفاتيح AWS ومقاطع الاستدعاء البرمجي لـ Slack وStripe.
- رموز الوصول والتوكنز الخاصة بـ GitHub والرموز المميزة لـ JWT.
- بيانات الاعتماد المخزنة في ملفات التهيئة المحلية .env وجلسات الاتصال SSH keys.
- بيانات المحافظ الرقمية للعملات المشفرة ومفاتيح الاسترداد وتهجئة كلمات المرور في متصفحات الإنترنت.
- أسرار بيئات Kubernetes والرموز المخزنة في منصات إدارة الأسرار مثل HashiCorp Vault.
السياق وتأثير السوق
يأتي هذا الهجوم ليعيد تسليط الضوء على الضعف الهيكلي في سلاسل توريد البرمجيات مفتوحة المصدر Software Supply Chain. إن الاعتماد الأعمى على مستودعات الحزم مثل Composer Packagist أو npm أو PyPI دون تطبيق ضوابط صارمة للتحقق يمثل خاصرة رخوة تستغلها مجموعات الجريمة الإلكترونية بشكل متزايد. في السابق، كانت أغلب الهجمات تعتمد على التسمم المطبعي typosquatting (تثبيت حزم بأسماء مشابهة) أو الاستيلاء المباشر على حسابات المطورين لنشر إصدارات أعلى رقماً. أما تقنية إعادة توجيه علامات الإصدارات التاريخية فتمثل تطوراً تكتيكياً خطيراً يلتف حول أدوات الفحص التلقائي التي تقارن أرقام الإصدارات فقط دون فحص البصمة الرقمية للالتزام المصدري commit hash. استجابت منصة Packagist سريعاً بعد تلقي البلاغات الأمنية، وقامت بإلغاء إدراج الحزم المصابة مؤقتاً وحذف الإصدارات الخبيثة لمنع تفاقم الضرر. ومع ذلك، فإن الطبيعة اللامركزية للمستودعات تعني أن مئات الشركات التي قامت ببناء بيئات التطوير الخاصة بها أو تحديث حزمها خلال فترة الهجوم قد تم اختراقها بالفعل دون علمها، مما يفرض خسائر اقتصادية غير مباشرة تتمثل في تكاليف التحقيق الجنائي الرقمي، وتغيير المفاتيح السحابية المشفرة، وإعادة تهيئة الخوادم الأمنية.رؤية Glitch4Techs
نرى في Glitch4Techs أن هذا الاختراق يمثل نقطة تحول في كيفية تقييم المطورين لمصداقية الحزم مفتوحة المصدر وطريقة التعامل مع Git كأداة لإدارة الإصدارات. إن إمكانية تعديل وإعادة كتابة علامات الإصدارات التاريخية force-pushing tags دون إطلاق تنبيهات أمنية واضحة في أدوات البناء التلقائي CI/CD تكشف عن فجوة أمنية تنظيمية تتطلب مراجعة جذرية. لا يمكننا بعد اليوم قبول علامات الإصدارات كدليل قاطع على سلامة الحزمة البرمجية. يجب على المطورين وفرق العمليات الأمنية اتخاذ تدابير فورية تتجاوز مجرد فحص الملفات المعتاد:- الاعتماد الصارم على تثبيت الحزم باستخدام البصمة الرقمية الكاملة للالتزام commit SHA بدلاً من الاعتماد على أرقام الإصدارات العادية في ملفات composer.json وcomposer.lock.
- تفعيل ميزة التوقيع الرقمي للالتزامات والبرمجيات الملتزم بها Commit Signing باستخدام مفاتيح GPG للتحقق من هوية المطور الحقيقي ورفض أي كود غير موقع.
- مراقبة حركة الاتصالات الشبكية الصادرة من الخوادم وبيئات التطوير والبحث عن أي اتصالات متجهة إلى النطاق المشبوه flipboxstudio[.]info أو أي خوادم تحكم مجهولة.
- سرعة تدوير وتغيير كافة المفاتيح السحابية والأسرار المخزنة في البيئات الحالية خشية أن تكون قد تسربت بالفعل إلى المهاجمين عبر البرمجية الخبيثة قبل إيقافها.
النشرة البريدية
كن أول من يعرف بمستقبل التقنية
أهم الأخبار والتحليلات التقنية مباشرة في بريدك.