الهجوم في فقرة واحدة
تعمل الدودة التي تسميها The Hacker News أول دودة سلسلة توريد ذاتية الانتشار في ثلاث خطوات. أولاً، يُثبّت مطور ضحية حزمة npm مخترقة — ناقل العدوى الأولي في المجموعة المُبلَّغ عنها علناً كان حزمة باسم pgserve وtyposquats أشقائها. ثانياً، يفحص سكريبت postinstall جهاز المطور بحثاً عن رموز مصادقة npm ورموز GitHub واعتمادات السحابة، يُصدّرها إلى نقطة تجميع المهاجم، ثم يستخدم رمز npm محلياً لنشر إصدار جديد خبيث من كل حزمة يملكها الضحية. تُؤكد تغطية BleepingComputer لنفس المجموعة أن هجوم سلسلة توريد npm ينتشر ذاتياً لسرقة رموز المصادقة بهذا النمط بالضبط. ثالثاً — وهذا ما يجعل الحادثة نقطة تحول — تُسقط الدودة أيضاً ملف Python .pth يعترض مفسر Python على نفس الجهاز، مما يتيح نشراً لاحقاً إلى PyPI من نفس المضيف المخترق.
النتيجة أن تثبيت واحد ناجح عند أي نقطة في رسم التبعيات يصبح عدوى متعددة المنظومات متتالية، تنتشر بهوية الضحية نفسه وسمعته.
لماذا “ذاتية الانتشار” مهمة
معظم هجمات سلسلة التوريد في السنوات الثلاث الماضية كانت طلقة واحدة. يُنشر typosquat، يُثبّته بضع مئات من المطورين، تُبلَّغ الحزمة الخبيثة وتُسحب، تُحاوَل النسبة، وتنتهي القصة. تكسر دودة pgserve هذا النمط لأن كل عدوى ناجحة تُنتج تلقائياً حزماً خبيثة إضافية منشورة من قبل مطورين ذوي سمعة مشروعة — وهذه الحزم بدورها تُعدي مزيداً من المطورين.
هناك خاصيتان تُكبّران نطاق الانفجار. أولاً، تتورط اعتمادات مشروعة: عمليات إعادة النشر الخبيثة موقّعة ومدفوعة بالرمز الحقيقي للمالك، مما يُبطل الكشف الساذج القائم على السمعة ومعظم استدلالات “ناشر جديد”. ثانياً، يملك صانعو الحزم الشائعة مستهلكين كثيرين في الأسفل؛ يمكن لصانع واحد مخترق لحزمة بـ 50,000 تثبيت أسبوعي إنتاج حدث تضخيم بـ 50,000 تثبيت في تحديث واحد لسجل npm.
أفادت The Hacker News كذلك بشكل متوازٍ أن جهات تهديد من كوريا الشمالية تنشر أكثر من 1,700 حزمة npm خبيثة عبر حملة منفصلة لكن متداخلة — دليل على أن منظومة الخصوم حول npm مزدحمة الآن بما يكفي لأن تعمل عدة جهات متطورة في نفس السجل في وقت واحد. يُطّر تحليل RapidFort الأطول الصورة الأوسع: PyPI وnpm والجبهة الجديدة لهجمات سلسلة توريد البرمجيات هما، بحسب حجتهم، الآن أكثر سطح الهجوم إنتاجاً ضد برمجيات المؤسسات.
تشريح حمولة pgserve
تحتوي حمولة دودة pgserve، المُعاد بناؤها من التقارير العامة، على أربعة مكونات يستحق فهمها لأن كل واحد يقابل ضابطاً دفاعياً محدداً:
حصاد postinstall. سكريبت postinstall في package.json يُنفَّذ عند كل npm install دون تأكيد المستخدم. يمشي السكريبت عبر نظام الملفات بحثاً عن .npmrc و.yarnrc و~/.config/gh/ و~/.aws/credentials و~/.docker/config.json، ويُحوّل الرموز المُكتشفة إلى خادم staging.
روتين إعادة النشر. يستخدم السكريبت بعدها رمز npm المحصود لاستدعاء npm publish على كل حزمة يملك الرمز حقوق كتابة عليها، مع حقن كود الدودة في كل إصدار منشور. لأن رمز الضحية نفسه مستخدم، يقبل السجل عمليات النشر دون مؤشرات شذوذ ترفعها أنظمة “ناشر غير معروف”.
خطّاف عبر المنظومات. يُكتب ملف .pth في site-packages Python للضحية. تُحمّل ملفات .pth عند بدء المفسر ويمكنها تنفيذ كود عشوائي — مما يعطي الدودة موطئ قدم في بنى Python على نفس المضيف، تستخدمه للامتداد إلى النشر في PyPI.
الثبات والقياس عن بعد. تُثبّت الدودة إدخال cron/launchd صغيراً وتُرسل beacon دورياً بقائمة الاعتمادات المرصودة حديثاً وعمليات نشر الحزم، مما يسمح للمشغّل بقياس فعالية الحملة بوقت شبه فوري.
إعلان
ما يُبطئ فعلاً دودة ذاتية الانتشار
الدفاعات التي تقلل الأثر ليست غريبة — إنها تلك التي أجّلتها فرق أمن المؤسسات لأن “سلسلة التوريد سنصل إليها يوماً ما”. تجعل حادثة pgserve “يوماً ما” هو اليوم.
تقييد نطاق رموز npm وتدويرها. كل رمز automation npm طويل الأمد هو ناقل محتمل للدودة. استخدم رموزاً قصيرة الأمد مقيّدة بالحزم المحددة التي تحتاج مهمة CI نشرها فعلاً، لا رموز read-and-publish واسعة دون قائمة حزم. يدعم كل من GitHub Actions وGitLab CI رموزاً عابرة عبر OpenID Connect federation — هذا التغيير وحده يُزيل معظم قدرة الدودة على إعادة النشر.
اشتراط 2FA عند النشر لجميع الصانعين. يدعم npm --auth-type=legacy لكنه يدعم أيضاً 2FA مدعوماً بـ WebAuthn عند النشر. عندما يتطلب كل نشر عاملاً ثانياً بحضور بشري، تنكسر حلقة إعادة النشر التلقائية للدودة. هذا مجاني، موجود بالفعل في السجل، ومُعطّل كثيراً لأجل الراحة.
تبني provenance المدعوم بـ Sigstore لحزمك الخاصة. يسمح مشروع Sigstore المدمج في npm كـ --provenance للناشرين بتوقيع شهادات البناء من نظام CI الذي أنتج الحزمة. يمكن للمستهلكين بعدها التحقق من أن الحزمة بُنيت في المستودع المتوقع بسير العمل المتوقع — مما يجعل إعادة نشر خبيثة من رمز مسروق تفشل بوضوح في فحص الشهادة. التبني لا يزال مبكراً، لكن العلم بجودة إنتاج.
قفل سكريبتات postinstall. استخدم npm install --ignore-scripts في CI للتبعيات غير الموثوقة، وعامل أي تبعية انتقالية جديدة تُشغّل postinstall على أنها تحتاج مراجعة يدوية. تُعيّن عدة مؤسسات كبرى الآن افتراضياً ignore-scripts=true في .npmrc وتُدرج حزماً محددة في قائمة سماح.
مراقبة ملفات .pth في بيئات Python. تنفيذ .pth هو فخ Python معروف لا تُشير إليه معظم أجهزة مراقبة سلسلة التوريد. أضف ضابطاً ينبه عند ظهور ملف .pth جديد في دليل site-packages خارج نشاط المُثبّت المعروف.
فصل اعتمادات المطورين عن الإنتاج. أعلى دفاع قيمة هو الممل: يجب ألا تحمل محطات عمل المطورين نفس الرموز التي تحملها خطوط أنابيب الإنتاج. افصل هويات النشر حسب البيئة، مع حدوث نشر الإنتاج فقط من CI، أبداً من laptop.
التحول الأكبر: سلسلة التوريد قادرة الآن على الديدان
كشف pgserve معلم هيكلي، لا مجرد حملة أخرى. طالما ظلت هجمات سلسلة التوريد typosquats منفردة، كانت مشكلة نظافة مطورين. الدودة ذاتية الانتشار التي تعبر المنظومات هي مشكلة استجابة للحوادث، لأن الاحتواء يتطلب عملاً منسقاً من مشغلي السجلات ومن عدة صانعين وربما آلاف من المستهلكين في الأسفل في غضون ساعات.
الدلالة لفرق أمن المؤسسات هي أن سياسة استهلاك المصدر المفتوح تحتاج إلى الصعود في سلم الأولويات. دودة تنشر حزماً باستخدام سمعة صانع مشروع تُهزم كل نظام كشف يعتمد على جدة الناشر أو إشارات سمعة ساكنة؛ الدفاعات المستدامة الوحيدة هي التشفيرية (provenance، شهادات موقّعة) والمعمارية (رموز مقيّدة، اعتمادات مجزأة).
الدلالة للصانعين هي أن نظافة النشر أصبحت الآن خارجية ذات عواقب نظامية. صانع واحد يُعطّل 2FA عند النشر لأجل الراحة يزيد الآن مادياً من سطح هجوم منظومة الانحدار بأكملها لحزمه.
دودة pgserve في أبريل 2026 هي الأولى من نوعها تصل الإنتاج. لن تكون الأخيرة.
ما ينبغي لفرق DevOps وهندسة المنصات تطبيقه هذا الربع
كشوف pgserve ليست مسوّغاً لمراجعة ممارسات سلسلة التوريد “يوماً ما” — بل هي مسوّغ لإنجاز ثلاثة تغييرات تهيئة هذا الشهر. كل واحد منها إعداد سياسة لا مشروع، وكل واحد يُزيل مباشرةً قدرة تحتاجها الدودة.
1. استبدال رموز npm طويلة الأمد برموز قصيرة فيدرالية عبر OIDC
كل رمز npm من نوع automation بنطاق read-and-publish ودون قائمة حزم هو ناقل محتمل للدودة. تستخدم دودة pgserve الرمز المحصود لاستدعاء npm publish ضد كل حزمة يملك الرمز حقوق كتابة عليها — رمز واسع يغطي 20 حزمة يُنتج حدث تضخيم بـ 20 حزمة من محطة عمل مطور مصابة واحدة. يدعم كل من GitHub Actions وGitLab CI فيدرالية OpenID Connect: يطلب نظام CI رمزاً قصيراً من السجل وقت التشغيل مقيّداً بالحزمة المحددة جارية النشر، وينتهي صلاحية هذا الرمز بعد اكتمال المهمة. لا يوجد اعتماد مستمر للحصاد. وفقاً لتحليل RapidFort لمجموعة pgserve، يُزيل هذا التغيير الوحيد قدرة الدودة الكاملة على إعادة النشر، حتى على الأجهزة المخترقة كلياً بحمولة postinstall الأولية. يستغرق الانتقال من الرموز الطويلة إلى OIDC federation من 4 إلى 8 ساعات لكل خط أنابيب ولا يتطلب أي تغييرات تهيئة لسجل npm.
2. تفعيل 2FA عند النشر لجميع الصانعين وقفل سكريبتات postinstall في CI
يدعم npm 2FA مدعوماً بـ WebAuthn عند فعل النشر. عندما يتطلب كل نشر عاملاً ثانياً بحضور بشري، تنكسر حلقة إعادة النشر التلقائية للدودة بصرف النظر عن سرقة الرمز. هذا مجاني، موجود بالفعل في سجل npm، ومُعطّل كثيراً لأجل الراحة في الفرق الكبيرة. نفّذ npm profile get 2fa لكل هوية نشر في منظمتك وفرّض الإعداد عبر سياستك الأمنية الداخلية. في المقابل، عيّن ignore-scripts=true في .npmrc المشترك للمنظمة وحافظ على قائمة سماح صريحة للحزم التي خضعت سكريبتات postinstall فيها للمراجعة والموافقة. تُؤكد تقارير The Hacker News عن الحملة المتزامنة لجهات تهديد من كوريا الشمالية — 1,700 حزمة npm خبيثة موزّعة عبر عملية منفصلة لكن متداخلة — أن عدة جهات متطورة تعمل في سجل npm في وقت واحد. فريق يُوقف تنفيذ postinstall للتبعيات غير الموثوقة يكسر ناقل العدوى الأولي لدودة pgserve وللفئة التي تمثّلها.
3. تبني provenance المدعوم بـ Sigstore لحزمك المنشورة والتنبيه عند إنشاء ملفات .pth
provenance المدعوم بـ Sigstore المدمج في npm كعلامة --provenance يسمح للناشرين بتوقيع شهادات البناء من نظام CI الذي أنتج الحزمة. يمكن للمستهلك الذي يتحقق من provenance التأكد من أن الحزمة بُنيت في المستودع المتوقع بسير العمل المتوقع — مما يجعل إعادة نشر خبيثة من رمز مسروق تفشل بوضوح في فحص الشهادة، حتى لو كتب الرمز المسروق بنجاح إلى السجل. التبني لا يزال مبكراً لكن العلم بجودة إنتاج ولا يكلّف سوى إضافة --provenance إلى أمر نشر CI. على صعيد الكشف، أضف تنبيه مراقبة نظام ملفات لأي ملف .pth جديد يظهر في دليل site-packages Python خارج نشاط المُثبّت المعروف — القفزة متعددة المنظومات لـ pgserve تعتمد على تنفيذ .pth، وهو فخ Python لا تُشير إليه معظم أجهزة مراقبة سلسلة التوريد. كلا الضابطين إضافيان ولا يُعطّلان خطوط الأنابيب الموجودة.
الدرس الهيكلي
يُعلن كشف pgserve عن عتبة لا مجرد حادثة. طوال معظم العقد الماضي، كانت هجمات سلسلة التوريد عمليات نسخ مزيف أحادية تتطلب جهداً من المهاجم لكل ضحية. يُحوّل نموذج الدودة المنتشرة بنية التكلفة هذه: تُنتج عدوى ناجحة واحدة تلقائياً حزماً خبيثة إضافية يُنشرها مطورون يحملون سمعةً شرعية، وكل واحدة من تلك الحزم تُنتج مزيداً من العدوى. يقترب الجهد المطلوب من المهاجم لكل ضحية إضافية من الصفر حين تُبذر الدودة. تصف تحليلات RapidFort لسطح هجوم PyPI وnpm هذا باعتباره سطح الهجوم الأكثر إنتاجية ضد برمجيات المؤسسات — ويؤكد كشف pgserve السبب: بيانات اعتماد المطورين المخزَّنة بشكل اعتيادي على الأجهزة المحلية، ورموز طويلة الأمد ذات نطاق حزمة واسع، وسكريبتات postinstall تُنفَّذ دون تأكيد المستخدم — تجتمع في سطح عدوى لا تستطيع أي ضوابط أمن محيطية معالجته.
الدرس الهيكلي يتعلق بمكان انتقال حدود التحكم. ضوابط المحيط والكشف عن التهديدات والاستجابة لها (EDR) تُمسك الهجمات التي تتحرك أفقياً بعد الوصول الأولي؛ لكنها لا تُمسك دودة تنتشر عبر سجل حزم عام باستخدام بيانات اعتماد مشرفين شرعيين. الضوابط التي تُبطئ فعلياً هذه الفئة من الهجمات — الرموز قصيرة العمر المُدارة عبر OIDC، و2FA على النشر، وشهادات provenance من Sigstore — تعمل جميعها على مستوى السجل وCI لا مستوى الشبكة. هذا الانتقال في الحدود يتطلب من فرق هندسة المنصات وDevOps امتلاك مشكلة أمنية أسندتها معظم المنظمات تاريخياً إلى فرق الشبكة أو نقطة النهاية. المنظمات التي تُجسّد هذا النقل في ملكية صراحةً عام 2026 — بوضع ضوابط سلسلة التوريد على جدول مراجعة السياسات ذاته مع قواعد جدار الحماية وسياسات EDR — ستكون في وضع ملائم جوهرياً للدودة التالية في هذه الفئة. أما المنظمات التي تعامل pgserve كحدث ترقيع وتمضي قدماً، فستفاجأ حين يستخدم الحادث التالي آلية الانتشار ذاتها ضد سجل آخر.
الأسئلة الشائعة
ما هي دودة سلسلة توريد ذاتية الانتشار؟
دودة سلسلة التوريد هي برمجية خبيثة تُسلَّم عبر حزمة مخترقة، بمجرد تثبيتها تستخدم اعتمادات الضحية المشروعة لنشر إصدارات حزم خبيثة إضافية، والتي بدورها تُعدي ضحايا جدداً. حادثة pgserve في أبريل 2026 هي أول مثال مُبلَّغ عنه على نطاق واسع يعبر أيضاً من npm إلى PyPI، باستخدام أحمال ملفات .pth للوصول إلى مفسر Python على نفس المضيف.
كيف يختلف هذا عن typosquatting أو الحزم الخبيثة التقليدية؟
يعتمد typosquatting على خطأ مطوّر في كتابة اسم حزمة ويمكن للدفاعات القائمة على السمعة القبض على الناشر المزيف. الدودة ذاتية الانتشار تستخدم رمز الصانع الحقيقي نفسه لإعادة نشر حزم مشروعة مع كود خبيث محقون. سمعة الناشر وتاريخ التنزيلات حقيقيان، مما يُبطل معظم استدلالات الكشف. provenance التشفيرية عبر Sigstore هي واحدة من الضوابط القليلة التي لا تزال تُشير إلى الإصدار الخبيث.
ما الدفاع الأعلى ROI ضد ديدان مثل pgserve؟
استبدال رموز أتمتة npm طويلة الأمد برموز قصيرة الأمد مقيّدة بالحزمة، صادرة عبر OIDC federation من CI. هذا يُزيل القدرة التي تحتاجها الدودة لإعادة نشر الحزم باعتمادات مسروقة، حتى لو أُصيب الجهاز الأولي. إنه تغيير تهيئة يستغرق ساعات لا أسابيع، ويقلل بشكل ذي مغزى من نطاق انفجار كل حادثة سلسلة توريد لاحقة.
