عودة «شاي-هولود»: دودة «ChainDrop» تضرب npm وتصيب مئات الحزم

في 4 أغسطس 2026، استولى أحد المهاجمين على حساب GitHub الخاص بمسؤول صيانة مكتبة «keyv» — وهي مكتبة للتخزين المؤقت بنظام المفتاح-القيمة ، والتي يُسجل عدد التنزيلات الأسبوعية منها عبر npm مئات الملايين تقريبًا — وقام بحقن دودة حاسوبية لسرقة بيانات الاعتماد عبر مجموعة الحزم الكاملة التابعة للمسؤول، بما في ذلك «cacheable» و«flat-cache» و«file-entry-cache» و«cache-manager». وقد انتشرت هذه الدودة، التي أُطلق عليها اسم ChainDrop، إلى مئات الحزم الإضافية التي يبلغ إجمالي عدد عمليات التثبيت الشهرية لها أكثر من ملياري عملية.

ما يجعل الأمر خطيرًا ليس عدد التنزيلات، بل الطريقة التي اكتسب بها الشفرة الخبيثة المصداقية. فقد نشر المهاجم الشفرة الخبيثة عبر مسار الإصدار الآلي الخاص بالمشروع نفسه، لذا كانت الإصدارات الملوثة تحمل مصدرًا صالحًا: دليلًا موقّعًا على أن الحزمة تم إنشاؤها بواسطة المسار الرسمي من المصدر الحقيقي. ومن المفترض أن يكون هذا الدليل إشارة أمان. وفي هذه الحالة، كان الدليل حقيقيًّا، لأن المسار نفسه تعرض للاختراق. وبالنسبة للمطور، أو لأداة الأمان التي تتحقق من التوقيع، بدت النسخة الخبيثة أصيلة تمامًا.

تُعد «ChainDrop» أحدث موجة في حملة يتتبعها الباحثون منذ سبتمبر 2025: «Shai-Hulud 1.0» (سبتمبر 2025)، و«2.0» (نوفمبر 2025)، و«Mini Shai-Hulud، الموجة الرابعة» (مايو 2026). وقد تصاعدت حدة كل موجة ، حيث أضافت المتغيرات اللاحقة طرق انتشار أكثر عدوانية واستغلالات أوسع نطاقًا لسلسلة التوريد.

• التاريخ: تم تأكيد أن «keyv@6.0.0» هي نقطة البداية، وقد نُشر ذلك في 4 أغسطس 2026.

• نقطة الدخول: بدأ الاختراق باختراق حساب أحد القائمين على الصيانة على GitHub، ثم تم نشر الإصدار الخبيث عبر مسار النشر الرسمي للمشروع.

• الحجم: تختلف الأرقام باختلاف الجهات التي تتعقب الحوادث، لكن جميع التقارير تتفق على أن هذه الحادثة كانت حادثة كبيرة جدًا في سلسلة التوريد الخاصة بـ npm. فقد أشارت شركة StepSecurity في وقت مبكر إلى 435 حزمة / 1,557 إصدارًا، في حين رفعت شركة Aikido والتقارير اللاحقة هذا العدد الإجمالي إلى مستويات أعلى، حيث تجاوزت بعض التقديرات 1,300 حزمة وحوالي 2 مليار عملية تنزيل شهريًا.

• الحمولة: يوجد مسار تثبيت مسبق باستخدام ملف setup.mjs، والذي يقوم بتنزيل برنامج «Bun» وتشغيل حمولة كبيرة مشوشة تهدف إلى سرقة بيانات الاعتماد.

• التصنيف: يصنف الباحثون هذا البرنامج ضمن عائلة البرامج الضارة «شاي-هولود».

ما يجعل «ChainDrop» مثيرًا للقلق بشكل خاص هو أنه لم يعتمد على ثغرة أمنية لافتة للنظر أو موقع تنزيل مزيف. بل استغل سلسلة التوريد العادية للبرامج — وهي نفس عملية نشر الحزم وتثبيتها التي يستخدمها ملايين المطورين.

من الناحية العملية، يعني ذلك أن الحزمة قد تبدو شرعية في حين أنها تحمل في الخفاء شفرة خبيثة يتم تنشيطها أثناء التثبيت. وتشير فرق الأمن إلى أن البرمجية الخبيثة صُممت لسرقة المعلومات السرية من أجهزة المطورين وأنظمة «التسليم المستمر/التكامل المستمر» (CI/CD)، بما في ذلك رموز GitHub وبيانات اعتماد npm ومفاتيح AWS والأسرار الخاصة بـ Kubernetes وغيرها من بيانات الوصول.

ولا يقتصر الخطر الأوسع نطاقاً على المطورين فحسب. فأي مؤسسة تستخدم الحزم المتأثرة قد تتعرض للاختراق بشكل غير مباشر من خلال أنظمة البناء والتبعيات ومسارات الإصدار الآلية.

يُعد ChainDrop تذكيرًا بأن التبعيات مفتوحة المصدر تشكل خطرًا تجاريًّا، وليست مجرد شاغل يخص المطورين فحسب.

بالنسبة لأي مؤسسة تعتمد على برمجيات JavaScript وNode.js، يُعد ChainDrop تذكيرًا بأن التبعيات مفتوحة المصدر تشكل خطرًا على الأعمال، وليست مجرد مصدر قلق للمطورين.

يمكن أن تنتقل الحزمة المخترقة بشكل غير مباشر عبر التبعيات وأنظمة البناء، وقد يؤدي ذلك إلى سرقة بيانات الاعتماد، والوصول غير المصرح به إلى البنية التحتية السحابية، وإجراء عمليات تدوير سرية على نطاق واسع، والاستجابة للحوادث. وحيثما تقع سلامة البرمجيات، والتحكم في الوصول، ومخاطر الأطراف الثالثة ضمن نطاق بيئة الرقابة الخاصة بك — كما هو الحال بموجب معايير PCI DSS وDORA وNIS2 وCMMC — فإن هذا التعرض يقع بشكل مباشر على عاتق الامتثال والحوكمة أيضًا.

إذا كنت قد قمت بتثبيت حزمة متأثرة في 4 أغسطس 2026 أو بعده:

• افحص التبعيات الخاصة بك: قم بإنشاء قائمة مكونات البرمجيات (SBOM) وافحص التبعيات للتأكد من عدم وجود إصدارات معروفة بخطورتها

• صورة قبل الإلغاء: صورة للأنظمة المتأثرة قبل تغيير الرموز. تراقب البرمجية الخبيثة عملية إلغاء بيانات الاعتماد، ويمكنها تشغيل معالج إذا قمت بتغيير الرموز أولاً.

• تغيير الأسرار المكشوفة: قم بتغيير كل سر يمكن الوصول إليه (رموز npm، ورموز PAT الخاصة بـ GitHub، ومفاتيح SSH، وبيانات اعتماد الخدمات السحابية) وفرض المصادقة متعددة العوامل (MFA)

• التحقق حسب الإصدار الدقيق، وليس حسب الاسم: المقارنة يجب أن تتم وفقًا للإصدار الدقيق الذي تم تحديده، وليس اسم الحزمة؛ حيث تغيرت علامات السجل أثناء الحادث

• قم بإزالة الروابط على مستوى المستودع: افحص ملفَي .claude/settings.json و.vscode/tasks.json، وليس فقط مجلد node_modules

• تدقيق CI/CD: قم بتدقيق CI/CD و GitHub Actions للكشف عن أي عمليات نشر غير متوقعة أو سير عمل جديد

والدرس المستفاد هو أن الدفاع الفعال ضد هذا النوع من الهجمات يكمن في فحص محتوى المكون، بدلاً من الاعتماد على مصدره.