Yusuf Khalidd

Posted on Apr 2 • Originally published at apidog.com

هجوم سلسلة الإمداد على axios@1.14.1: ماذا تفعل الآن؟

#npm #node #security #javascript

باختصار

في 30-31 مارس 2026، تم اختراق الإصدارات 1.14.1 و 0.30.4 من axios على npm من خلال تبعية خبيثة تسقط حصان طروادة للوصول عن بعد (RAT) على الأجهزة المصابة. تم سحب كلا الإصدارين. الإصدار الآمن هو 1.14.0. إذا قمت بتثبيت axios@1.14.1 أو 0.30.4، اعتبر جهازك مخترقًا ودوّر جميع بيانات الاعتماد فورًا.

جرّب Apidog اليوم

ما هو axios ولماذا هذا مهم

axios يحصل على أكثر من 100 مليون تحميل أسبوعيًا من npm. هو عميل HTTP أساسي في معظم أطر عمل الواجهة الأمامية وخدمات Node.js وتطبيقات المؤسسات. اختراق حزمة بهذا الحجم يفتح الباب لهجوم واسع النطاق — أي مطور نفذ npm install في الفترة الحرجة بين 30 و31 مارس ربما قام بتنزيل برمجيات خبيثة دون علمه.

هذا ليس تهديدًا افتراضيًا؛ حدث بالفعل وحُمّل RAT متقدم قادر على تنفيذ أوامر عشوائية وسرقة أسرار النظام والبقاء بشكل مستمر على الجهاز.

إذا كنت تستخدم axios مع Apidog لتصميم واختبار تكاملات عميل HTTP لديك، نفذ الخطوات التالية قبل أي نشر جديد.

الجدول الزمني للهجوم

30 مارس 2026 — 23:59:12 UTC: نشر حزمة خبيثة plain-crypto-js@4.2.1 على npm بواسطة حساب بريد nrwise@proton.me. تم نشر إصدار نظيف سابق 4.2.0 كـ typosquat لمكتبة crypto-js.
31 مارس 2026 — 00:05:41 UTC: Socket تكتشف تلقائيًا الحزمة الخبيثة بعد 6 دقائق فقط من نشرها.
31 مارس 2026 — بعد منتصف الليل: نشر axios@1.14.1 على npm، مع وجود plain-crypto-js@4.2.1 كـ تبعية. الإصدار غير موجود في GitHub. آخر إصدار شرعي هو v1.14.0.
31 مارس 2026 — صباحًا: بلاغ علني على GitHub (#10604) باختراق axios@1.14.1 وaxios@0.30.4. لم يكن لدى الصائنين القدرة على نزع وصول المهاجم فورًا.
31 مارس 2026: إزالة الإصدارات الخبيثة من npm. يبدأ فريق axios بإلغاء الرموز المميزة وتشديد النشر والتحقيق في استغلال الرمز المميز طويل الأمد.

كيف تم الهجوم

استُغل رمز npm مميز طويل الأمد مرتبط بحساب صائن في عملية نشر موثوقة. نشر المهاجم إصدارًا جديدًا من axios خارج إجراءات الإصدار الرسمية، وأضاف تبعية plain-crypto-js@4.2.1 (اسم مقنع). الإصدار النظيف السابق أسس تاريخًا للحزمة.

داخل plain-crypto-js@4.2.1، تم العثور على حمولة متعددة المراحل:

المرحلة 1 — التنفيذ: تشغيل كود عند تثبيت الحزمة (عبر lifecycle scripts) لإسقاط حمولة ثانوية.
المرحلة 2 — نشر RAT: تثبيت حصان طروادة دائم يفتح بابًا خلفيًا.
المرحلة 3 — السرقة: RAT قادر على تنفيذ أوامر شل عشوائية، قراءة أسرار البيئة والملفات، وإرسال بيانات النظام.

يبقى RAT قائمًا حتى بعد إزالة الحزمة ما لم تتم إزالته يدويًا.

هل أنت متأثر؟

أنت متأثر على الأرجح إذا:

شغلت npm install axios أو npm install (مع وجود axios في package.json) بين 30 مارس، 23:59 UTC و 31 مارس 2026، منتصف النهار UTC.
ملف node_modules/axios/package.json لديك يعرض الإصدار 1.14.1 أو 0.30.4.
ملف package-lock.json أو yarn.lock يحل axios إلى 1.14.1 أو 0.30.4.

تحقق فورًا عبر الأوامر التالية:

# التحقق من الإصدار المثبت
npm list axios

# التحقق من ملف القفل
grep '"axios"' package-lock.json | head -5

# التحقق من وجود plain-crypto-js
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "مصاب" || echo "غير موجود"

إذا وجدت plain-crypto-js في node_modules، فقد تم تشغيل الكود الضار على جهازك.

ماذا تفعل الآن

1. تحديث axios فورًا

npm install axios@1.14.0
# أو التثبيت على أحدث إصدار آمن
npm install axios@latest

تحقق من الإصدار:

npm list axios
# يجب أن يظهر 1.14.0 أو أعلى

2. إذا قمت بتثبيت الإصدار المخترق

لا تتعامل مع هذا كمجرد تحديث تبعية. اعتبر الجهاز مخترقًا ونفذ:

تدوير جميع الأسرار التي يمكن الوصول إليها من هذا الجهاز: مفاتيح API، بيانات اعتماد قواعد البيانات، مفاتيح SSH، رموز السحابة، متغيرات .env.
تحقق من متغيرات البيئة — RAT يستهدف الأسرار تحديدًا.
دقق في الشبكة الصادرة خلال فترة الاختراق — ابحث عن اتصالات مشبوهة.
ابحث عن الاستمرارية — راجع مهام cron، ونصوص بدء التشغيل، وخدمات systemd المضافة حديثًا.
أعد تهيئة الجهاز إذا كان خادم CI أو إنتاج. إذا كان جهاز مطور، دوّر جميع البيانات قبل اعتباره آمناً.

3. دقق في مسارات CI/CD الخاصة بك

إذا شغّل مسار البناء npm install أثناء فترة الهجوم، قد تكون بيئة CI مخترقة.

# تحقق من سجلات البناء للنافذة الزمنية
# ابحث عن axios@1.14.1 في إخراج التثبيت

# تحقق من node_modules الحالي
npm list axios plain-crypto-js

قم بتدوير كل الأسرار التي يمكن لـ CI الوصول إليها.

4. التحقق من ملفات القفل

إذا كان package-lock.json أو yarn.lock يحتوي على 1.14.1، احذفه وأعد إنشاؤه:

rm package-lock.json
npm install

تأكد أن القفل الجديد يحل axios لإصدار آمن قبل الالتزام.

استخدام Apidog لتدقيق مكالمات API الخاصة بـ axios

بعد تحديث axios، تحقق من أن تكاملات API لديك ما زالت سليمة باستخدام Apidog. استورد نقاط النهاية إلى Apidog ونفّذ اختبارات تراجع للتأكد من عدم تغيير السلوك.

مثال اختبار تأكيد في Apidog:

// تأكيد Apidog بعد الاستجابة
pm.test("الاستجابة نظيفة — لا توجد حقول محقونة", () => {
    const body = pm.response.json();
    pm.expect(body).to.not.have.property('__injected');
    pm.expect(pm.response.headers.get('X-Injected-Header')).to.be.null;
});

اختبر كل نقاط النهاية بعد التحديث، وتأكد أن جميع الطلبات/الاستجابات تعمل كما كان متوقعًا.

جرّب Apidog مجانًا لإعداد اختبارات تراجع شاملة لتكاملات HTTP الخاصة بك.

لماذا يصعب إيقاف هجمات سلسلة التوريد على npm

هذه ليست أول مرة يحدث فيها هذا النوع من الهجمات:

event-stream (2018): إضافة حمولة تستهدف محافظ البيتكوين.
ua-parser-js (2021): إسقاط عامل تعدين عملات مشفرة وسارق كلمات مرور.
node-ipc (2022): رمز ضار يستهدف عناوين IP معينة.
xz utils (2024): زرع باب خلفي في مكتبة ضغط أساسية.
axios (2026): نشر RAT عبر تبعية خبيثة بعد اختراق حساب صائن.

النمط المشترك: الثقة في حساب النشر، وليس الكود البرمجي.

إجراءات تخفيفية فعالة:

الإجراء	ما يفعله
ملفات القفل (`package-lock.json`)	تثبيت الإصدارات، منع الترقيات الصامتة
`npm audit` في CI	كشف الثغرات قبل النشر
Socket.dev / Snyk	تحليل سلوكي للحزم
المصادقة الثنائية على npm	صعوبة اختراق الحسابات
رموز نشر قصيرة العمر	تقليل فترة التعرض
مراجعة ملفات القفل في PRs	اكتشاف تغييرات التبعيات غير المصرح بها

فريق axios بدأ بالفعل بتشديد الضوابط، لكن الحل يجب أن يكون على مستوى النظام البيئي ككل.

مؤشرات الاختراق (IOCs)

حسب تحليل Socket:

الحزم الضارة: plain-crypto-js@4.2.1، axios@1.14.1، axios@0.30.4
البريد الإلكتروني للناشر: nrwise@proton.me
السلوك: اتصالات شبكة عند تثبيت npm، استمرارية RAT، سرقة متغيرات البيئة
إصدارات axios الآمنة: 1.14.0 وما قبل (باستثناء 0.30.4)، 1.13.x، 1.12.x

إذا كنت تشتبه في إصابة، أبلغ أمن npm عبر security@npmjs.com واحتفظ بالسجلات.

الخلاصة

اختراق axios 1.14.1 يؤكد أن أمان التبعيات عملية مستمرة. ثبّت إصداراتك، شغل أدوات تحليل سلوكي مثل Socket في CI، دوّر الأسرار عند الشك، وراجع ملفات القفل بدقة في مراجعة الكود.

إذا احتجت لاستعادة الثقة في تكامل واجهات برمجة التطبيقات بعد تحديث axios، يمنحك Apidog سيناريوهات الاختبار والتأكيدات وأدوات المحاكاة للتحقق من سلوك عميل HTTP قبل النشر.

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

ما هي إصدارات axios التي تم اختراقها؟

axios@1.14.1 و axios@0.30.4. تم سحب كلاهما من npm. الإصدار الآمن هو 1.14.0 أو أي إصدار من سلاسل 1.13.x، 1.12.x.

ماذا تفعل الحمولة الضارة؟

تسحب plain-crypto-js@4.2.1 التي تطلق حمولة متعددة المراحل تتضمن RAT يمكنه تنفيذ أوامر عن بعد وسرقة أسرار البيئة والبقاء بشكل دائم.

كيف أعرف إذا كنت قد نصبت الإصدار المخترق؟

نفذ npm list axios — إذا ظهر 1.14.1 أو 0.30.4، أنت متأثر. تحقق من npm list plain-crypto-js — وجود الحزمة يعني تشغيل الكود الضار.

هل يكفي تحديث axios فقط؟

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

كيف تمكن المهاجم من النشر على npm؟

غالبًا باختراق بيانات اعتماد صائن واستخدام رمز npm مميز طويل الأمد لديه صلاحية النشر. فريق axios يعالج الأمر ويشدد الضوابط.

ما الفرق بين هذا ونقطة ضعف تقليدية؟

نقطة الضعف عيب في الكود الشرعي. هجوم سلسلة التوريد يضيف كودًا ضارًا عبر قناة نشر موثوقة. الكود المخترق لم يظهر مطلقًا في GitHub بل حُقن مباشرة في npm.

كيف أحمي مشاريعي من هجمات سلسلة التوريد القادمة؟

استخدم ملفات القفل، شغل npm audit في CI، أضف Socket.dev للتحليل السلوكي، فعّل المصادقة الثنائية، استخدم رموز نشر قصيرة العمر، ودقق ملفات القفل في مراجعة الكود.

DEV Community