كشفت Microsoft Threat Intelligence تفاصيل هجوم واسع على سلسلة توريد npm طال أكثر من 400 حزمة مرتبطة بناشرين غير متصلين ظاهرياً، من بينها حزم ضمن منظومات برمجية مؤسسية مثل keyv وflat-cache وcache-manager. تضمنت الإصدارات الخبيثة نسخة من دودة Mini Shai-Hulud، وهي حمولة JavaScript مبنية على Bun ومموهة بدرجة كبيرة، صُممت لسرقة الاعتمادات والانتشار تلقائياً عبر إعادة نشر تحديثات ضارة.
ويمنح هذا الهجوم أهمية خاصة لطريقة عمله؛ فالبرمجية لا تكتفي بسرقة الرموز من جهاز مطور أو بيئة بناء، بل تستغل تلك الرموز للوصول إلى npm وGitHub وAmazon Web Services وKubernetes وHashiCorp Vault، ثم تفحص الموارد والأسرار التي تسمح بها الهويات المسروقة. ووفق تحليل Microsoft المنشور في 4 أغسطس 2026، ينبغي التعامل مع أي محطة عمل أو عامل بناء استورد حزمة متأثرة، مع تفعيل سكربتات دورة حياة npm، على أنه معرض للاختراق.
تنفيذ مبكر داخل بيئات التطوير
أُضيف إلى الإصدارات المتأثرة عادةً سكربت preinstall يشغّل ملفاً باسم setup.mjs قبل اكتمال تثبيت الحزمة. ويطلق الملف حزمة Bun كبيرة ومموهة، ما يسمح بتنفيذ الحمولة على أجهزة المطورين وعُقد البناء قبل بدء اختبارات التطبيق أو وصول بعض فحوصات الأمان التقليدية إلى هذه المرحلة.
تفحص الدودة البيئة أولاً لتحديد ما إذا كانت تعمل على محطة مطور أو ضمن مهمة CI/CD. وعلى أجهزة المطورين، تفصل نفسها لتواصل التنفيذ في الخلفية بعد انتهاء التثبيت، بينما تبقى مرتبطة بالمهمة في بيئات CI/CD للاستفادة من أسرار سير العمل، واعتمادات العامل، وصلاحيات النشر عبر OpenID Connect. كما تتحقق من عدم تشغيل نسخة أخرى، وتتوقف على الأنظمة ذات اللغة الروسية وفق ما رصدته Microsoft.
سرقة الاعتمادات وتحويلها إلى انتشار
تبدأ الحمولة بجمع ما هو متاح محلياً من ملفات الاعتماد، ومتغيرات البيئة، وسجل الأوامر، ومفاتيح SSH، وأدوات السحابة، إضافة إلى بيانات من ذاكرة عمال GitHub Actions. وتحاول، من بين أمور أخرى، الحصول على رمز GitHub CLI. بعد ذلك تستخدم الاعتمادات المستخرجة لاستدعاء واجهات خدمات npm وGitHub وAWS وKubernetes وHashiCorp Vault والتحقق من الصلاحيات وجمع أسرار إضافية.
تُشفّر النتائج بصيغة JSON مضغوطة باستخدام AES-256-GCM، مع تشفير مفتاح AES عبر RSA-OAEP-SHA256، ثم تُرسل إلى نقطة HTTPS يتحكم بها المهاجم. ويستخدم GitHub كقناة بديلة لاستخراج البيانات عند تعذر القناة الأساسية. وأشارت Microsoft إلى أن البنية النشطة في وقت التحليل أعادت النطاق npm-cache[.]com، فيما ظهرت مرشحّات سابقة مثل pypi-get[.]com وjs-mirror[.]com.
أما آلية الانتشار الأساسية، فتفحص رموز npm لمعرفة ما إذا كانت تتيح الكتابة إلى الحزم أو تجاوز المصادقة الثنائية، ثم تنزّل أحدث ملف tarball لكل حزمة متاحة للهوية المخترقة. وتنسخ الدودة نفسها إلى الأرشيف، وتضيف محمّل الإعداد وسكربت دورة الحياة، وترفع رقم الإصدار التصحيحي قبل إعادة النشر. ويفسر ذلك ظهور إصدارات ضارة تبدو كتحديثات patch عادية من دون commit أو طلب دمج أو وسم إصدار مطابق في مستودع المصدر.
مسارات إضافية عبر GitHub
تتحقق الحمولة من نطاقات رموز GitHub، وتحصي المستودعات القابلة للكتابة، وتبحث عن مستودعات يمكن أن تكشف فيها عمليات سير العمل أسراراً أخرى. كما تتضمن مساراً يستهدف حزم npm المنشورة عبر GitHub Actions باعتبارها جهات نشر موثوقة، ما قد يمنح الإصدارات المنشورة provenance صالحاً لأن النشر يأتي من هوية سير عمل شرعية.
وتستطيع الدودة أيضاً حقن ملفات إعداد داخل فروع المستودعات، بما في ذلك مسارات مرتبطة بـ Claude وVisual Studio Code مثل .claude/settings.json و.claude/setup.mjs و.vscode/tasks.json و.vscode/setup.mjs. وتوفر هذه التعديلات مسار عدوى ثانوياً يمكن أن يعيد تشغيل الحمولة أثناء استخدام Claude أو Visual Studio Code، حتى بعد انتهاء تثبيت الحزمة الأصلية. وذكرت Microsoft أن أحد مسارات GitHub الاحتياطية يحاول كذلك تثبيت مكوّن لمراقبة الرموز، مع معالج تخريبي مشروط عند إلغاء الرمز المراقَب.
ما الذي توصي به Microsoft؟
توصي Microsoft بتحديث npm CLI إلى الإصدار 12 واستخدام ميزة min-release-age، ومراجعة أشجار الاعتماد وملفات القفل ومستودعات المصنوعات وذاكرات CI بحثاً عن الإصدارات الخمسة المتأثرة، بما في ذلك المراجع غير المباشرة. كما ينبغي تثبيت إصدارات معروفة السلامة، ومسح ذاكرات npm وyarn على أجهزة المطورين ومضيفات البناء، خصوصاً عندما تكون الأرشيفات المخترقة قد دخلت إلى ذاكرة CI مشتركة.
إذا استورد نظام بناء أو محطة عمل إصداراً متأثراً، يجب تدوير الاعتمادات والأسرار من جهاز نظيف، لأن التنفيذ من المرحلة الثانية قد يكشف الرموز ويؤثر في سلامة عملية البناء. وتشمل التوصيات أيضاً تفعيل الحماية السحابية لبرنامج Microsoft Defender Antivirus، وقياسات Microsoft Defender for Endpoint، وMicrosoft Defender for Containers، وسير عمل التحقيق في Microsoft Defender XDR عبر أصول التطوير وCI.
ولا تقتصر الاستجابة على فحص الأجهزة. فعلى الجهات التي تنتج المصنوعات البرمجية مراجعة تحصين عملية الإصدار، ونطاقات الرموز، وموافقات سير العمل، والبيئات المحمية، وإثبات مصدر الإصدار، وآليات رصد النشر الآلي غير المعتاد، لأن الحادثة تتسق مع إساءة استخدام خطوط CI/CD عبر صلاحيات GitHub Actions OIDC. وبعد المعالجة، ينبغي إعادة بناء المشاريع من خط أساس موثوق، والتأكد من غياب البصمات المخترقة من الذاكرات ومستودعات المصنوعات، ومراجعة القياسات بحثاً عن بقايا Node.js مثل Math_Symbol.js وMath_init.js أو ملفات بأسماء شبيهة بـ math_<guid>.js، مع إعادة بناء الصور الأساسية وعمال البناء المعياريين.