Shai-Hulud وأزمة سلسلة توريد npm لعام 2026

إن شغّلت npm install يوم ثلاثاء في عام 2026، فربما تكون قد شحنت برمجية خبيثة تخصّ شخصًا آخر. وهذا ليس مبالغة. ففي الفترة بين سبتمبر 2025 ويونيو 2026، انتقل سجلّ npm من مصدر إزعاج عرضي يقوم على انتحال أسماء الحزم (typosquatting) إلى مسرحٍ لأول دودة حقيقية ذاتية التكاثر يشهدها نظام JavaScript البيئي على الإطلاق. وأزمة سلسلة توريد npm لعام 2026 هي قصة كيف توقّف المهاجمون عن التصيّد الاحتيالي لمطوّرين منفردين وبدؤوا بتسليح الثقة التي تتيح لحزمة واحدة أن تسحب بهدوء ثلاثمئة حزمة أخرى.

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

الدودة التي تنشر نفسها: Shai-Hulud

كان الحدث المحوري هو Shai-Hulud، المسمّى نسبةً إلى دودة الرمال في رواية فرانك هربرت Dune (كثيب). ووفقًا لفريق Unit 42 التابع لشركة Palo Alto Networks، انطلقت الموجة الأولى في 15 سبتمبر 2025، وتُعدّ أول دودة حقيقية ذاتية التكاثر في نظام npm البيئي.

والآلية خبيثة في بساطتها. فالدودة تُنفَّذ أثناء التثبيت عبر نصوص دورة حياة الحزمة، وتحصد بيانات الاعتماد من المضيف، ثم تستخدم أي رموز نشر npm مسروقة لإعادة نشر حزم الصائن الضحية الأخرى بالحمولة الخبيثة نفسها. وأشار Unit 42 إلى أنها كانت تُعدّد نحو أعلى 20 حزمة يصونها الضحية وتعيد نشرها، مُحدِثةً تتابعًا متسلسلًا. وتتبّعت Sysdig وغيرها الموجة الأصلية إلى نحو 200 حزمة مصابة، من بينها مكتبات واسعة الاستخدام مثل @ctrl/tinycolor وngx-bootstrap.

ولم يتوقف الأمر عند ذلك. فقد تطوّرت عائلة الحملة عبر ثلاث موجات موثّقة:

• الأصلية (سبتمبر 2025): نحو 200 حزمة، حصاد لبيانات الاعتماد إضافةً إلى حلقة النشر التلقائي.
• Shai-Hulud 2.0 (نوفمبر 2025): أفاد Unit 42 بأن الحمولة انتقلت إلى التنفيذ في مرحلة ما قبل التثبيت (pre-install)، ما يعني أنها كانت تُشغَّل على كل خادم بناء تقريبًا يعالج حزمة مصابة، لا على حواسيب المطوّرين المحمولة فحسب.
• Mini Shai-Hulud (أواخر أبريل 2026): كُشف عنها لأول مرة قرابة 29 أبريل 2026، وضربت هذه الموجة npm وPyPI في آنٍ واحد للمرة الأولى. وتتبّعها تحالف أمن السحابة (Cloud Security Alliance) وSecuronix عبر نحو 172 حزمة و404 إصدار خبيث، مع تنزيل الحزم المصابة مجتمعةً مئات الملايين من المرات أسبوعيًا.

وأضافت نسخة Mini Shai-Hulud حيلة جديدة مرعبة: الاستمرارية عبر ملفات إعداد وكلاء البرمجة بالذكاء الاصطناعي، بما في ذلك إعدادات Claude Code وVS Code. فقد أدركت الدودة أن المطوّرين المعاصرين يعيشون داخل أدوات الذكاء الاصطناعي، فزرعت نفسها هناك.

Axios: حين تتمرّد 100 مليون عملية تنزيل أسبوعية

الديدان مرعبة لأنها تتوسّع. والاختراقات المستهدِفة للحزم البارزة مرعبة بسبب نطاق الانفجار. ففي 30 مارس 2026، تعرّضت Axios — أشهر عميل HTTP في نظام JavaScript البيئي، بأكثر من 100 مليون عملية تنزيل أسبوعية من npm — للاختراق وتحوّلت إلى وسيلة توصيل لحصان طروادة للوصول عن بُعد (RAT) متعدّد المنصات.

ونسبت Microsoft Threat Intelligence اختراق Axios والبنية التحتية الداعمة له إلى Sapphire Sleet، وهو جهة فاعلة كورية شمالية موالية للدولة. وحين تُزرع باب خلفي في تبعية تقبع تحت شريحة معتبرة من جميع تطبيقات Node.js، يتوقف السؤال عن أن يكون "هل نحن معرّضون؟" ويصبح "بأي سرعة يمكننا أن نكتشف ذلك؟".

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

Red Hat وOIDC ونقطة العمى في CI/CD

قد تكون أكثر حوادث 2026 إفادةً هي الأصغر نطاقًا. ففي 1–2 يونيو 2026، اخترق المهاجمون ما لا يقل عن 32 حزمة منشورة ضمن مساحة الأسماء @redhat-cloud-services على npm — أي 96 إصدارًا إجمالًا، وفقًا لـ Aikido Security، بأكثر من 116,000 عملية تنزيل تراكمية.

وما يجعل هذه الحالة ذات أهمية هو كيفية حدوثها. فوفقًا لـ Cybersecurity Dive وWiz، نُشرت الإصدارات الخبيثة عبر GitHub Actions OIDC بدلًا من بيانات اعتماد npm مسروقة. إذ دفع حساب GitHub مخترَق تعديلات (commits) غير مصرّح بها إلى مستودعات في منظمة RedHatInsights، فنشر خط التكامل المستمر النتيجة بكل طاعة. وكانت الحمولة نسخة من Mini Shai-Hulud — دودة سارقة لبيانات الاعتماد تتصيّد أسرار CI وبيانات اعتماد السحابة ومفاتيح SSH ورموز npm.

وذكرت Red Hat أن الكود الخبيث لم يُنشر قط للاستخدام من قِبل العملاء وأنه أثّر فقط في حزم التطوير الداخلية. لكن الخلاصة عامة: إن كانت هوية CI/CD لديك قادرة على النشر، فإن اختراق هوية CI/CD يكفي. فهجمات سلسلة توريد npm في 2026 تتجاوز بشكل متزايد الصائن البشري كليًا وتتجه مباشرةً نحو الأتمتة التي تنشر نيابةً عنه.

لماذا تفاقم الأمر إلى هذا الحد وبهذه السرعة

ثلاث حقائق بنيوية حوّلت حوادث منعزلة إلى أزمة منهجية:

• الثقة العابرة. يحتوي مشروع Node نموذجي على آلاف التبعيات العابرة. أنت تتحقق من تبعياتك المباشرة؛ لكنك لا تتحقق من تبعياتها أبدًا تقريبًا.
• نصوص دورة الحياة. خطّافات preinstall وpostinstall تُشغّل كودًا اعتباطيًا أثناء التثبيت افتراضيًا. وهذه هي بدائية التنفيذ التي اعتمدت عليها كل دودة من هذه الديدان.
• الرموز في كل مكان. رموز نشر npm الطويلة الأمد وبيانات اعتماد السحابة الواسعة القابعة في بيئات CI هي بالضبط ما صُمّمت الديدان السارقة لبيانات الاعتماد لانتزاعه — ثم إعادة استخدامه للانتشار.

كيف تدافع عن خط معالجتك الآن

لا يمكنك تدقيق كل تبعية عابرة يدويًا. لكن يمكنك تقليص مساحة الهجوم تقليصًا كبيرًا بضوابط تتطابق مباشرةً مع آلية عمل هذه الهجمات.

أوقف تنفيذ الكود وقت التثبيت

• شغّل npm install --ignore-scripts في CI افتراضيًا، وأدرج ضمن قائمة السماح الحفنة من الحزم التي تحتاج فعلًا إلى نصوص بناء.
• اضبط ignore-scripts=true في ملف .npmrc الخاص بمشروعك ليكون الوضع الافتراضي آمنًا.

اقفل وتحقّق ممّا تثبّته

• ثبّت ملف القفل (lockfile) واستخدم npm ci لا npm install في عمليات البناء الآلية لتُثبَّت الإصدارات بدقة.
• فعّل --foreground-scripts في npm وراجع الحزم التي تُحَل من سجلّات غير متوقعة (ناقل ارتباك التبعيات الكلاسيكي الذي نبّهت إليه Microsoft في مايو 2026).
• أضف فترة تهدئة: تجنّب الترقية التلقائية إلى إصدارات نُشرت في آخر 24–72 ساعة، وهي النافذة التي تُكتشف فيها معظم هذه الإصدارات الخبيثة وتُسحب.

عامِل بيانات اعتماد CI بوصفها درّة التاج

• استبدل رموز نشر npm الطويلة الأمد بـ رموز قصيرة الأمد ومحدّدة النطاق، وفعّل النشر الموثوق / إثبات المصدر (provenance) في npm كي تُوقَّع الحزم مقابل بناء مصدرها.
• حدّد نطاق GitHub Actions OIDC لمستودعات وبيئات بعينها؛ فحالة Red Hat تُظهر أن هويات النشر المفرطة الاتساع هي الهدف السهل الجديد.
• دوّر أي مفاتيح AWS ورموز HashiCorp Vault ومفاتيح SSH مكشوفة لمشغّلات البناء، وفضّل الأسرار الفورية (just-in-time) على الأسرار الثابتة.

راقب أدوات الذكاء الاصطناعي لديك

إن استمرارية Mini Shai-Hulud عبر ملفات إعداد Claude Code وVS Code تعني أن محرّرك وإعدادات الوكلاء صارت الآن جزءًا من مساحة الهجوم. أبقِ هذه الإعدادات في نظام التحكّم بالمصدر كي تكون التغييرات غير المتوقعة مرئيةً في الفرق (diff).

الخلاصة

جعلت أزمة سلسلة توريد npm لعام 2026 أمرًا واحدًا لا يقبل الإنكار: السجلّ بنية تحتية، والبنية التحتية تتعرّض للهجوم. أثبت Shai-Hulud أن دودة قادرة على الانتشار من صائن إلى صائن دون مساعدة بشرية، وأثبت Axios أن أكثر الحزم موثوقيةً هي أعلى الأهداف قيمةً، وأثبت اختراق Red Hat عبر OIDC أن المهاجمين سيتخطّون المطوّر ويتجهون مباشرةً نحو الروبوت الذي ينشر. ولا شيء من الدفاعات الواردة أعلاه غريب أو معقّد — فتعطيل نصوص التثبيت، والتثبيت بـ npm ci، واستبدال الرموز الطويلة الأمد بنشر مدعوم بإثبات المصدر كان كفيلًا بكبح كل موجة وُصفت هنا. والفرق التي اجتازت 2026 سالمةً لم تكن محظوظة. بل توقّفت ببساطة عن الوثوق بـ npm install افتراضيًا.

الأسئلة الشائعة

هل لا يزال Shai-Hulud نشطًا في 2026؟ تطوّرت عائلة الحملة عبر ثلاث موجات على الأقل حتى منتصف 2026، مع نشاط Mini Shai-Hulud من أواخر أبريل 2026 ونشاط مرتبط (مثل اختراق Red Hat) ظهر في يونيو. عامِله بوصفه نمط تهديد مستمرًا، لا حادثًا مغلقًا.

هل يلتقط npm audit هذه الهجمات؟ ليس بموثوقية في الوقت الفعلي. فـ npm audit يُعلِم بالثغرات المعروفة بعد أن تُفهرس. أما الإصدارات الخبيثة المنشورة حديثًا فيمكن أن تنتشر لساعات قبل الكشف عنها، ولهذا تكون ضوابط وقت التثبيت وفترات تهدئة الإصدارات أهم من التدقيق وحده.

هل تتأثر PyPI وسجلّات أخرى أيضًا؟ نعم. كان Mini Shai-Hulud أول موجة تضرب npm وPyPI في عملية منسّقة واحدة، لذا تنطبق مبادئ الدفاع نفسها عبر الأنظمة البيئية.