دودة npm خبيثة ضربت مئات الحزم يوم 4 أغسطس 2026، وفتحت باب سرقة بيانات المطورين وبيئات CI مع توسع سريع في نطاق الهجوم.
ما هي دودة npm الخبيثة التي أصابت مئات الحزم؟
الهجوم بدأ من الإصدار keyv@6.0.0 قبل أن يمتد إلى نطاقات أخرى وحزم عديدة داخل سجل npm. ومع تسارع التعديلات على الإصدارات، أصبح تتبع القائمة الكاملة للحزم المتأثرة أكثر تعقيداً خلال ساعات قليلة فقط.
التحليلات الأمنية أشارت إلى مئات الإصدارات الملوثة عبر عشرات الأسماء، ثم ارتفع التقدير لاحقاً إلى أرقام أكبر بكثير. وهذا يعني أن تأثير دودة npm الخبيثة لم يعد محصوراً في مكتبة واحدة، بل تحول إلى حملة تسميم واسعة لسلسلة التوريد البرمجية.
كيف بدأ الانتشار؟
الإصدار الخبيث استغل سكربت preinstall ليعمل تلقائياً عند تثبيت الحزمة داخل أجهزة المطورين أو أنظمة التكامل المستمر. وبعد التنفيذ، يبدأ بجمع بيانات حساسة ثم يحاول استخدام صلاحيات النشر المتاحة لتلويث حزم إضافية.
- بداية الهجوم المؤكدة: keyv@6.0.0
- آلية التنفيذ: preinstall script
- بيئة الاستهداف: أجهزة المطورين وCI
- هدف الانتشار: إعادة نشر حزم ملوثة بصلاحيات مسروقة
كيف تعمل دودة npm الخبيثة داخل بيئة المطور؟
الحمولة الخبيثة لم تعدل الكود البرمجي الأساسي للمكتبة بشكل واضح، بل أضافت ملفات جديدة وأوامر تثبيت خفية. هذا الأسلوب يجعل الاكتشاف أصعب، لأن الحزمة قد تبدو سليمة وظيفياً للمستخدم العادي.
في المرحلة الأولى، تتحقق البرمجية من وجود Bun، وإذا لم يكن متاحاً يتم تنزيله ثم تسليم التنفيذ إلى ملف مجمع كبير الحجم. بعد ذلك تبدأ عملية جمع الأسرار الرقمية من الجهاز أو الخادم المصاب.
- تنزيل مكونات إضافية أثناء التثبيت
- جمع رموز GitHub وnpm
- الوصول إلى مفاتيح خاصة وبيانات سحابية
- استهداف Vault وKubernetes وقواعد البيانات
- محاولة استخدام هوية npm المسروقة لإعادة النشر
ما البيانات التي قد تتم سرقتها من الحزم المصابة؟
الخطر هنا لا يقتصر على كلمة مرور واحدة، بل يشمل مواد اعتماد حساسة قد تسمح للمهاجم بالوصول إلى المستودعات، السحابة، ومفاتيح النشر. كما رُصدت قدرة على قراءة بيانات من ذاكرة مشغلات GitHub Actions، وهو تطور خطير في هجمات سلسلة التوريد.
الأخطر أن بعض المشاريع احتفظت أيضاً بخطافات مرتبطة بـ Claude Code وVisual Studio Code، ما قد يسمح بتشغيل الحمولة بعد منح الثقة لمساحة العمل أو قبول إعدادات المشروع. ووفقاً لمتابعة تيكبامين، فهذا يوسع دائرة الخطر من التثبيت الأولي إلى بيئة التطوير نفسها.
- رموز وصول للمستودعات البرمجية
- بيانات اعتماد npm registry
- مفاتيح وخدمات سحابية
- مفاتيح خاصة وشهادات
- بيانات من بيئات التشغيل الآلي
ماذا يجب أن يفعل المطورون الآن بعد هجوم npm؟
أي جهاز أو خادم نفذ إصداراً متأثراً يجب اعتباره مكشوف البيانات حتى يثبت العكس. لذلك لا يكفي حذف الحزمة فقط، بل يجب فحص ملفات القفل والإصدارات المحلولة وسجل التثبيت بدقة.
كما ينبغي عدم تدوير الرموز والمفاتيح مباشرة قبل إزالة آلية المراقبة التي تترصد عملية الإبطال. ويختم تيكبامين بأن مواجهة دودة npm الخبيثة تتطلب جرداً دقيقاً للحزم، تحديث عميل npm إن أمكن، وتعطيل أي مسارات تثبيت تسمح بتشغيل lifecycle scripts بدون تدقيق.
- تحديد اسم الحزمة والإصدار الفعلي من lockfile
- عزل الأجهزة أو runners المصابة
- إزالة آلية المراقبة المحلية أولاً
- تدوير الرموز والمفاتيح بعد التنظيف
- مراجعة صلاحيات النشر في npm والمستودعات
