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

Ashley Innocent

Ashley Innocent

2 أبريل 2026

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

Apidog للمؤسسات

نشر محلي

SSO & RBAC

متوافق مع SOC 2

استكشاف Apidog Enterprise

باختصار

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

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

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

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

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

زر

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

30 مارس 2026 — 23:59:12 بالتوقيت العالمي المنسق: تم نشر حزمة ضارة تسمى plain-crypto-js@4.2.1 على npm بواسطة حساب يستخدم nrwise@proton.me. تم نشر إصدار نظيف سابق (4.2.0) قبل 18 ساعة كـ typosquat مقنع لمكتبة crypto-js الشرعية.

31 مارس 2026 — 00:05:41 بالتوقيت العالمي المنسق: تقوم خاصية اكتشاف البرامج الضارة التلقائية من Socket بوضع علامة على plain-crypto-js@4.2.1 كبرنامج ضار — بعد ست دقائق من نشره.

31 مارس 2026 — بعد منتصف الليل بوقت قصير: تم نشر axios@1.14.1 على npm، مما يسحب plain-crypto-js@4.2.1 كـ تبعية. لا يظهر هذا الإصدار في العلامات الرسمية لمستودع axios على GitHub. تظل أحدث علامة شرعية هي v1.14.0.

31 مارس 2026 — صباحًا: تم فتح مشكلة GitHub #10604 علنًا للإبلاغ عن اختراق كل من axios@1.14.1 و axios@0.30.4. يؤكد صائنو Axios أنهم لا يستطيعون في البداية إلغاء وصول المهاجم — فالحساب المخترق لديه أذونات npm أعلى من الصائنين الشرعيين.

31 مارس 2026: تم إلغاء نشر كل من axios@1.14.1 و axios@0.30.4 من npm. يبدأ صائنو Axios في إلغاء الرموز المميزة، وتشديد ضوابط النشر، والتحقيق في كيفية استغلال رمز npm مميز طويل الأمد للحصول على وصول غير مصرح به للنشر.

كيف تم الهجوم

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

قدم الإصدار الجديد plain-crypto-js@4.2.1 كـ تبعية. تم تصميم اسم الحزمة ليبدو وكأنه أداة تشفير شرعية؛ الإصدار النظيف السابق 4.2.0 أنشأ تاريخًا قصيرًا لتقليل الشك.

داخل plain-crypto-js@4.2.1، وجد تحليل Socket حمولة متعددة المراحل:

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

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

هل أنا متأثر؟

من المحتمل أن تكون متأثرًا إذا:

تحقق فورًا:

# التحقق من الإصدار المثبت
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 أو أعلى (بمجرد نشر 1.14.x نظيف)

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

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

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

إذا قام مسار البناء الخاص بك بتشغيل npm install خلال النافذة، فقد تكون بيئة CI الخاصة بك قد تعرضت للاختراق. تحقق:

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

# تحقق من أن node_modules الحالي لـ CI نظيف
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 كعميل HTTP الخاص بك لاستدعاء واجهات برمجة التطبيقات (APIs)، يمكن أن يساعدك Apidog في التحقق من أن تكاملك لا يزال يرسل الطلبات الصحيحة بعد تحديث التبعية.

بعد التحديث إلى axios@1.14.0، قم باستيراد نقاط نهاية API الموجودة لديك إلى 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;
});

تشغيل مجموعة الاختبار الكاملة الخاصة بك مقابل إصدار axios المحدث في Apidog يمنحك أساسًا نظيفًا موثقًا قبل الدفع إلى الإنتاج.

جرب Apidog مجانًا لإعداد اختبارات تراجع عميل HTTP.

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

هجوم axios ليس شذوذًا. إنه نمط:

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

إجراءات التخفيف التي تساعد فعلاً:

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

أقر فريق axios منذ ذلك الحين أن رموز npm المميزة طويلة الأمد كانت جزءًا من المشكلة ويتحركون نحو ضوابط نشر أكثر صرامة. لكن الإصلاح يجب أن يأتي من النظام البيئي بأكمله، وليس فقط من الحزم الفردية.

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

وفقًا لتحليل Socket:

إذا كنت تشك في الإصابة، أرسل تقريرًا إلى أمن 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).

ماذا تفعل حمولة axios الضارة؟ إنها تسحب plain-crypto-js@4.2.1، التي تنشر حمولة متعددة المراحل تتضمن حصان طروادة للوصول عن بعد (RAT). يمكن لحصان طروادة تنفيذ أوامر عشوائية من خادم C2 بعيد، وسرقة متغيرات البيئة والأسرار، والبقاء عبر عمليات إعادة التشغيل.

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

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

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

ما الفرق بين هذا ونقطة ضعف عادية؟ نقطة الضعف هي عيب في الكود الشرعي. هجوم سلسلة التوريد يقدم كودًا ضارًا عبر قناة نشر موثوقة. لم يكن الكود المخترق موجودًا أبدًا في مستودع axios على GitHub — بل تم حقنه مباشرة في نشر npm.

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

ممارسة تصميم API في Apidog

اكتشف طريقة أسهل لبناء واستخدام واجهات برمجة التطبيقات