هجوم Shai-Hulud على npm: دودة سرقت الأسرار وانتشرت ذاتيًا عبر آلاف الإصدارات

كيف بدأ الاختراق؟

حوالي الساعة 09:00 بالتوقيت العالمي المنسق (UTC)، سيطر المهاجم على حساب GitHub المرتبط بـ Jared Wray، واستخدم الصلاحية للوصول إلى الفرع main في مستودع keyv ودفع شيفرة خبيثة، ثم إصدار نسخ جديدة عبر عائلة حزم keyv وcacheable .

شملت الدفعة الأولى 11 حزمة ضمن النطاقين نفسيهما، بينها keyv وcacheable-request وcache-manager و@cacheable/utils وflat-cache وfile-entry-cache وحزم أخرى . وأكد باحثون من Aikido Security وStepSecurity، التي تتبع الحملة باسم ChainDrop، وSocket وChainguard وقوع الاختراق خلال الساعات الأولى .

ماذا احتوت الحزم الملوثة؟

أضيف إلى كل حزمة متأثرة ملفان جديدان:

• setup.mjs
• Math_Symbol.js

كما عُدّل ملف package.json لإضافة خطاف التثبيت المسبق:

"preinstall": "node setup.mjs"

وعندما يشغّل مطوّر أو نظام بناء مستمر الأمر npm install، يعمل setup.mjs تلقائيًا قبل اكتمال التثبيت. وتتمثل مهمته في تنزيل نسخة شرعية من بيئة تشغيل JavaScript المسماة Bun من إصدارات GitHub، ثم استخدامها لتشغيل الحمولة الثانية المشفرة والمموهة في Math_Symbol.js، التي بلغ حجمها نحو 710 إلى 728 كيلوبايت .

وأكدت Microsoft Threat Intelligence أن الحمولة تنتمي إلى متغير من Mini Shai-Hulud . وقد صُممت لجمع طيف واسع من الأسرار وبيانات الدخول الموجودة في بيئات التطوير والبناء، من بينها :

• رموز المصادقة في npm
• رموز الوصول الشخصية إلى GitHub (PATs)
• مفاتيح AWS
• أسرار Kubernetes
• رموز HashiCorp Vault
• مفاتيح Stripe
• رموز Slack
• مفاتيح SSH
• ملفات حالة Terraform
• بيانات اعتماد Docker
• إعدادات الشبكات الافتراضية الخاصة (VPN)

لماذا انتشرت الدودة بهذه السرعة؟

لم تكن الحملة مجرد تلويث لحزم المشرف الأصلي. فبعد سرقة رموز نشر الحزم في npm ورموز GitHub الشخصية من البيئة المصابة، استخدمت الدودة تلك الصلاحيات لنشر إصدارات خبيثة من حزم يملكها مشرفون آخرون لا علاقة مباشرة لهم بعائلة keyv .

وتسارعت الأرقام على النحو الآتي:

• خلال نحو ساعتين، سجلت StepSecurity إصابة 435 حزمة و1557 إصدارًا .
• وبحلول أوائل فترة بعد الظهر بتوقيت وسط أوروبا الصيفي (CEST)، أحصت Aikido Security 868 حزمة مصابة عبر 1381 إصدارًا .
• وبنهاية اليوم، تجاوز العدد 1280 حزمة و1680 إصدارًا، وفقًا لـ BleepingComputer ومصادر أخرى .

كما تجاوزت الدودة حدود النطاقات البرمجية التي بدأت منها، ووصلت إلى حزم مرتبطة بمنظمات مثل Deliveroo وOrnikar وOneReach وPicsart وQlik وServiceTitan، إلى جانب جهات أخرى .

أين أُرسلت البيانات المسروقة؟

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

ماذا يجب أن تفعل الفرق المتأثرة؟

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

1. تثبيت الإصدارات أو الرجوع إلى نسخ سليمة

أوقف التحديثات التلقائية، وثبّت الحزم على إصدارات معروفة بأنها سليمة أو ارجع إلى إصدارات سابقة للهجوم. ويمكن استخدام آليات overrides في package.json مع npm أو Yarn أو pnpm لمنع إعادة تثبيت النسخ الملوثة .

افحص أيضًا ملفات القفل، بما فيها package-lock.json وyarn.lock وpnpm-lock.yaml، وابحث عن الحزم المتأثرة سواء كانت اعتماديات مباشرة أو غير مباشرة .

2. عزل الأجهزة وبيئات CI/CD

لا تواصل استخدام جهاز مطوّر أو خادم بناء شغّل npm install لنسخة متأثرة وكأن المشكلة اقتصرت على مجلد node_modules. يجب عزله والتحقيق فيه، ويفضل إعادة بنائه من صورة نظيفة بدل الاكتفاء بالتنظيف داخل النظام .

3. إلغاء جميع بيانات الاعتماد وإصدارها من جديد

ألغِ وأعد إنشاء كل سر أو رمز كان متاحًا على الجهاز المصاب، بما في ذلك :

• رموز npm، التقليدية والمجزأة
• رموز GitHub الشخصية والرموز الدقيقة الصلاحيات
• مفاتيح AWS وبيانات اعتماد IAM
• رموز حسابات خدمة Kubernetes
• رموز HashiCorp Vault
• مفاتيح Stripe
• رموز Slack
• مفاتيح SSH
• بيانات اعتماد Docker
• رموز VPN

4. عطّل مراقبات إلغاء الرموز قبل تدويرها

هذه من أكثر التفاصيل حساسية في الاستجابة. فقد تنشئ البرمجية أحيانًا مراقبات ضمن GitHub Actions أو سير عمل تراقب إنشاء الرموز الجديدة، ثم تكشف الرمز الجديد فور إصداره . لذلك أوصى الباحثون بإيقاف هذه المراقبات أو إزالتها أولًا، ثم تدوير بيانات الاعتماد .

5. امسح ذاكرات التخزين وأعد البناء

امسح ذاكرات npm وpnpm وYarn، إضافة إلى ذاكرات بناء Docker، من أجهزة المطوّرين وخوادم CI/CD . ثم أعد بناء الحزم والمنتجات من الصفر، حتى لا تبقى اعتماديات ملوثة داخل طبقات Docker أو ملفات البناء المؤقتة .

6. راجع GitHub وبيئات التطوير

ابحث عن مستودعات أُنشئت حديثًا أو مهام سير عمل غير مصرح بها، وراجع سجلات النشاط والصلاحيات . كما ينبغي فحص آثار الاستمرارية التي ربما أنشأتها الدودة، مثل .claude/settings.json و.vscode/tasks.json .

الخلاصة

أثبت هجوم Shai-Hulud في 4 أغسطس 2026 أن اختراق حساب مشرف واحد يمكن أن يتحول خلال ساعات إلى أزمة واسعة في سلسلة توريد البرمجيات، حتى عندما لا يملك الحساب وصولًا مباشرًا إلى معظم الحزم التي ستتأثر لاحقًا.

واستخدمت الحملة عدة عناصر زادت من خطورتها: تشغيلًا تلقائيًا عبر preinstall، وتنزيل بيئة Bun شرعية لتشغيل الحمولة، وسرقة رموز تتيح إعادة النشر، وقنوات متعددة لإخراج البيانات .

وبالنسبة إلى فرق الهندسة والأمن، تقدم الحادثة تذكيرًا عمليًا بأهمية تثبيت الاعتماديات، وتقليل أو تعطيل نصوص preinstall وpostinstall عندما يكون ذلك ممكنًا، ومراقبة نشاط GitHub غير المعتاد، والاحتفاظ بخطط استجابة جاهزة لحوادث اختراق سلسلة توريد البرمجيات.