ماذا فعلت Shai-Hulud 2.0 ولماذا تهم
تم الكشف عن دودة Shai-Hulud الأولى في سبتمبر 2025 — حصرت الجدولة الزمنية من Unit 42 وتنبيه CISA أكثر من 500 حزمة مصابة وحددا حملة التصيد لحصاد بيانات الاعتماد التي بذرتها. كان ذلك غير مسبوق في وقته.
ظهرت Shai-Hulud 2.0، أو «المجيء الثاني»، في 24 نوفمبر 2025 وكانت أكثر أتمتة وعدوانية وتدميراً. وثّق Datadog Security Labs ومدوّنة Microsoft Security في 9 ديسمبر 2025 الآليات:
- حين تُثبَّت حزمة مُخترَقة، يُسقط سكريبت preinstall ملفين ضارين (`setup_bun.js` و`bun_environment.js`).
- يحصد السكريبت بيانات الاعتماد المحلية: رموز npm، وبيانات Git، وأسرار سحابة AWS وGoogle Cloud وAzure.
- تُسرَّب بيانات الاعتماد المسروقة إلى مستودع GitHub عام موسوم بـ «Sha1-Hulud: The Second Coming».
- باستخدام رمز npm المسروق، تحدد الدودة الحزم الأخرى التي يُشرف عليها المطوّر المُخترق وتنشر تلقائياً إصدارات backdoored — حتى 100 حزمة لكل مطور مصاب.
- الآلية التدميرية الاحتياطية. إذا لم تستطع الدودة تسريب البيانات أو الانتشار (لا رمز GitHub أو npm، منع خروج الشبكة)، تقوم الحمولة بالكتابة فوق ومحو جميع الملفات القابلة للكتابة في دليل المستخدم الرئيسي للمطور.
أنتج Elastic وSonatype وReversingLabs كلها تحليلات تقنية مستقلة في أول 48 ساعة، وأصبح دليل الدفاع المجتمعي dont-be-shy-hulud على GitHub المرجع الفعلي للإصلاح.
لماذا ألغت npm جميع الرموز القديمة
في 9 ديسمبر 2025، اتخذت npm الخطوة النادرة بإلغاء جماعي لجميع الرموز «الكلاسيكية» القديمة عبر المستودع. وفقاً لـ تحليل Microsoft، كان التفكير مباشراً: كانت الرموز الكلاسيكية توفر سلطة نشر واسعة وطويلة الأمد استخدمتها الدودة للانتشار أسرع مما يستطيع الإلغاء اليدوي مواكبته. بإجبار كل مُشرف على الانتقال إلى رموز محدودة النطاق ومحدودة الوقت، أزالت npm المُسرّع الرئيسي.
هذا هو التغيير الهيكلي الأكثر أهمية في نظام npm البيئي منذ سنوات. كل خط أنابيب CI/CD ينشر حزمة باستخدام رمز كلاسيكي تعطّل في 9 ديسمبر. السباق للترحيل — وخطوط الأنابيب التي لا تزال معطلة اليوم لأن لا أحد لاحظ — هو في حد ذاته مؤشر على نظافة سلسلة التوريد.
ما الذي يجب على كل فريق هندسي فعله في 2026
تتعمّم آليات الدودة إلى ما بعد حادث واحد. ستتبع أي دودة من نوع npm مستقبلاً نفس النموذج: اختراق مُشرف واحد، سرقة رمزه، دفع إصدارات backdoored من حزمه، تكرار. يجب لذلك أن يكون الدفاع هيكلياً، لا ارتجالياً.
- سحب رموز npm الكلاسيكية في كل مكان. دقّق كل خط أنابيب CI/CD وworkstation مطور ومتجر بيانات اعتماد بحثاً عن إدخالات `_authToken` في ملفات `.npmrc`. استبدلها برموز وصول محبّبة (GATs) محدودة النطاق لحزم محددة بنوافذ انتهاء صلاحية قصيرة، أو بتدفقات trusted-publisher (OIDC) حيث توجد.
- MFA مقاوم للتصيد لكل حساب مُشرف. تتبّع الاختراق الأصلي لـ Shai-Hulud إلى حملة تصيد تنتحل تحديثات MFA الخاصة بـ npm. مفاتيح FIDO2 العتادية لـ npm وGitHub وأي حساب package registry هي الآن السقف الأدنى لأي شخص ينشر شفرة يُثبّتها مستخدمون في أسفل السلسلة.
- تعطيل سكريبتات preinstall وpostinstall افتراضياً. ينبغي أن يكون `npm install –ignore-scripts` الافتراضي في CI/CD، لا الاستثناء. شغّل السكريبتات فقط للحزم المُراجَعة عبر allowlist. تُكوّن كثير من المنظمات هذا في `.npmrc` مشترك عبر الأسطول.
- الانتقال إلى بيانات اعتماد CI/CD مؤقتة. الرموز طويلة الأمد في خطوط الأنابيب هي كيفية انتقال هذه الفئة من الهجوم أفقياً إلى نظام البناء. بيانات الاعتماد قصيرة الأمد المرتبطة بهوية عمل (OIDC من GitHub Actions إلى npm، اتحاد أدوار IAM إلى السحابة) تزيل سطح الهجوم الثابت.
- كشف شذوذ preinstall في CI. راقب المكالمات الشبكية وقت التثبيت، وكتابات الملفات في `$HOME`، وإنشاءات مستودعات GitHub غير المتوقعة من منفذي CI. نشر Datadog وElastic وSnyk وSocket وAikido كلها قواعد كشف لمؤشرات Shai-Hulud 2.0 يمكن تكييفها لمتغيرات مستقبلية.
- تثبيت إصدارات التبعيات بملفات lockfiles. يمنع `package-lock.json` أو `pnpm-lock.yaml` السحب الانتهازي لإصدار ضار تم نشره للتو. بالاقتران مع provenance موقّع عبر تكامل sigstore الخاص بـ npm، يرفع ذلك السقف مادياً.
- الحفاظ على بيئة تثبيت في الحجر الصحي لاختبارات التشغيل الأولى. ينبغي تثبيت التبعيات الجديدة أولاً في VM معزول بدون بيانات اعتماد دائمة. أي حزمة تمد يد طور التثبيت إلى نقطة نهاية شبكة غير متوقعة أو تكتب خارج دليلها ينبغي أن تُشغّل تحقيقاً قبل أن تهبط في البيئة الرئيسية.
إعلان
دليل الاستجابة الفورية إذا كنت تعتقد أنك مصاب
إذا اشتبه مطور في أن Shai-Hulud 2.0 (أو متغيراً) نشط على جهازه، تتقارب إرشادات حادث StepSecurity ومدوّنة Microsoft على ثلاثة إجراءات فورية:
- لا تشغّل `npm install` على أي مشروع. إن أمكن، افصل عن الشبكة. يمنع ذلك كلاً من استمرار الانتشار وتشغيل الآلية التدميرية إن لم تكن الحمولة قد اكتملت بعد.
- ألغِ جميع رموز المطور — npm وGitHub وAWS وGoogle Cloud وAzure — فوراً. ألغِ أولاً، دوّر لاحقاً. إذا دوّرت قبل الإلغاء، تستطيع الدودة سرقة بيانات الاعتماد الجديدة.
- نظّف الجهاز قبل تدوير بيانات الاعتماد. أعد تثبيت OS أو استعد من نسخة احتياطية معلومة نظيفة. أصدر بيانات اعتماد جديدة فقط بمجرد أن تكون بيئة التطوير خالية من الحمولة بشكل يمكن التحقق منه.
للمنظمات، أضف: انشر نشرة CISO إلى فرق الهندسة خلال 24 ساعة، وتحقق من جميع بيانات اعتماد نشر الحزم المشتركة، ودقّق آخر 30 يوماً من الحزم الجديدة المنشورة من حسابات المنظمة.
ماذا يعني هذا للمحادثة الأوسع لسلسلة التوريد
يوضح منظور 2026 من Dark Reading حول ديدان سلسلة التوريد النقطة الهيكلية بصراحة: أثبتت Shai-Hulud، على نطاق واسع، أن نظام الحزم يمتلك آلية تكاثر متاحة لأي مهاجم متحفّز بما يكفي. كانت npm الأولى بسبب حجمها وتساهل سكريبتات preinstall، لكن PyPI وRubyGems وMaven Central وNuGet تتشارك ضعفاً هيكلياً مماثلاً.
ثلاثة تغييرات اتجاهية ينبغي أن تكون على لوحة تحكم 2026 لكل CISO.
- التعامل مع package registries كبنية تحتية إنتاجية لسلسلة التوريد. ينبغي أن تتلقى الوصول والتدقيق والنظافة الصرامة نفسها التي تتلقاها قواعد بيانات الإنتاج.
- تبني provenance موقَّع حيثما كان متاحاً. تكامل sigstore الخاص بـ npm، وناشرو Python الموثوقون PEP 740، والبرامج المماثلة في أنظمة أخرى تسد فجوة المساءلة.
- استجواب الموردين حول نظافة package registry الخاصة بهم. ينبغي أن تشمل تقييمات المخاطر التابعة في 2026 أسئلة محددة حول MFA ونطاق الرمز وتوقيع provenance على خطوط أنابيب بناء المورد.
أين يترك ذلك فرق الهندسة
Shai-Hulud 2.0 هو أوضح حادث سلسلة توريد رآه معظم قادة الهندسة، ولن يكون الأخير. العمل الدفاعي — ترحيل الرموز، MFA مقاوم للتصيد، `–ignore-scripts`، provenance — مفهوم جيداً، مُجهّز بشكل متزايد، ومجاني أو رخيص في كل حالة. المنظمات التي عاملت حادث نوفمبر 2025 كجرس إنذار في وضع أفضل جوهرياً من تلك التي عاملته كمشكلة شخص آخر. السؤال لكل CTO يقرأ هذا في أبريل 2026 بسيط: كم خطوة من دليل العمل أعلاه تم شحنها فعلاً؟
الأسئلة الشائعة
هل منظمتي معرّضة حتى لو لم ننشر حزم npm؟
نعم. مستهلكو حزم npm هم الضحايا الأساسيون لدودة مثل Shai-Hulud — تُفعّل الآلية التدميرية على جهاز المطور خلال `npm install`. أي منظمة تشغّل مشاريع Node.js أو خطوط أنابيب CI/CD تثبّت تبعيات أو workstations مطورين بـ npm هي داخل نصف قطر الانفجار بغض النظر عمّا إذا كانت تنشر حزمها الخاصة.
ما الفرق بين Shai-Hulud 1 وShai-Hulud 2.0؟
Shai-Hulud 1، المُكشف عنها في سبتمبر 2025، أصابت أكثر من 500 حزمة npm وتتبّعت إلى حملة تصيد لحصاد بيانات الاعتماد تنتحل تحديثات MFA الخاصة بـ npm. Shai-Hulud 2.0، التي ظهرت في 24 نوفمبر 2025، كانت أكثر أتمتة بشكل كبير: تعمل خلال طور preinstall قبل أي فحوص أمنية، وتقوم تلقائياً بـ backdoor ما يصل إلى 100 حزمة لكل مطور مصاب، وتضم آلية تدميرية تكتب فوق دليل المستخدم الرئيسي للمطور إذا فشل التسريب. معاً، أصابتا مئات الحزم الفريدة وآلاف مستودعات GitHub.
هل يؤثر هذا على Yarn أو pnpm أو package managers أخرى؟
نعم، لأن الدودة تستهدف بيانات وصفية للحزم الأساسية (سكريبتات preinstall وبيانات اعتماد المُشرف)، لا المثبّت المحدد. مستخدمو Yarn وpnpm الذين يثبّتون من مستودع npm معرّضون للحزم backdoored نفسها. التوصيات الدفاعية — تعطيل سكريبتات preinstall افتراضياً، سحب الرموز الكلاسيكية، استخدام MFA العتادية، تثبيت lockfiles — تنطبق على package managers الثلاثة.
المصادر والقراءات الإضافية
- دودة npm Shai-Hulud 2.0: التحليل وما تحتاج معرفته — Datadog Security Labs
- Shai-Hulud 2.0: إرشادات الكشف والتحقيق والدفاع — Microsoft Security Blog
- دودة «Shai-Hulud» تخترق نظام npm البيئي — Unit 42 (Palo Alto)
- التعامل مع دودة Shai-Hulud 2.0 — Elastic Security Labs
- فهم هجوم دودة npm Shai-Hulud — Sonatype
- Shai-Hulud 2.0 تنتشر. إليك ما تحتاج معرفته — ReversingLabs
- اختراق واسع النطاق لسلسلة التوريد يؤثر على نظام npm البيئي — CISA
- Shai-Hulud: دودة ذاتية النسخ تخترق أكثر من 500 حزمة NPM — StepSecurity
- ديدان سلسلة التوريد في 2026: ما علّمته Shai-Hulud للمهاجمين — Dark Reading
- dont-be-shy-hulud — دليل الدفاع المجتمعي (GitHub)
