هجوم Axios في 2026: لماذا لا تثبت شجرة اعتماديات نظيفة سلامة بيئة البناء

ما الذي حدث، وما الذي يضيفه هذا التحليل؟

في 31 مارس 2026، نُشرت نسختا axios الخبيثتان 1.14.1 و0.30.4 عبر حساب مخترق لأحد المشرفين على المشروع. يحدد تقرير المشرف الاعتمادية المضافة باسم plain-crypto-js@4.2.1 ويصف إيصال برمجيات خبيثة إلى منصات متعددة. [1] ويضع تحليل Microsoft مسار التنفيذ في مرحلة تثبيت الحزم، لا في تغيير المنطق المعتاد للشيفرة المصدرية لعميل HTTP. [2]

يقترح هذا المقال نموذجًا لأدلة التعافي: تحديد ما ثُبّت، وما نُفّذ، والصلاحيات التي أمكن لذلك التنفيذ الوصول إليها. تساعد هذه الأسئلة مالك المنتج على تحديد الأنظمة ومخرجات الإصدار التي تحتاج إلى اهتمام، دون اعتبار كل ظهور لاعتمادية دليلًا على اختراق مؤكد. يستند التحليل إلى سجلات عامة جرى التحقق منها في 4 أكتوبر 2026؛ ولا يدّعي الوصول إلى بيئات المتضررين أو إجراء تجارب جديدة على البرمجيات الخبيثة.

التثبيت حدّ للتنفيذ، حتى دون استيراد المكتبة

يحدد JFrog آلية postinstall؛ ولم يتطلب التنفيذ استيراد المكتبة داخل التطبيق. [3] والنتيجة بالنسبة للمراجعة هي ضرورة فحص إمكانية الوصول عبر الشيفرة وإمكانية الوصول أثناء التثبيت كلًّا على حدة. فقد تغفل مراجعة تقتصر على سؤال ما إذا كان التطبيق يستورد مكتبة مشبوهة عن المرحلة التي أصبحت فيها الآلة معرضة للخطر.

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

registry publication
  -> dependency resolution
  -> package installation
  -> lifecycle-script execution
  -> runner identity and reachable credentials
  -> repositories, signing systems, deployments

The package tree is one evidence source.
The execution history is a different evidence source.

كيف يمكن أن تكون الشجرة نظيفة الآن رغم تنفيذ خبيث سابق؟

يفيد JFrog بحذف المُحمّل واستبدال ملف وصف الحزمة الخاص به بعد التنفيذ. [3] ويعني ذلك للمحقق أن فحص الملفات لاحقًا قد يعطي سجلًا تاريخيًا ناقصًا. لا يعني هذا أن كل أدوات الفحص غير فعالة؛ بل إن فحص الحالة الراهنة والتحقيق في تاريخ التنفيذ يجيبان عن سؤالين مختلفين.

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

ارسم الصلاحيات عبر الزمن، لا تكتفِ بأسماء متغيرات البيئة

أعلنت OpenAI تنفيذ Axios الخبيث داخل سير عمل لتوقيع التطبيقات وتغيير الشهادة احترازيًا، دون أدلة على اختراق بيانات المستخدمين أو تعديل البرمجيات. [4] يوضح هذا ضرورة تقييم التعرض ضمن حدود دقيقة بدل تحويله إلى عنوان غير مدعوم عن تسريب بيانات. يجب أن يميز التحقيق بين الموارد التي أمكن لسير العمل الوصول إليها وتلك التي استخدمها المهاجم بالفعل وفق الأدلة.

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

استخدم ثلاث حالات للأدلة بدل تصنيف ثنائي: متأثر أو غير متأثر

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

احتفظ بقيمة «غير معروف» عند غياب السجلات. نقص بيانات مراقبة التنفيذ لا يثبت أن السكربت لم يعمل قط. وبالمثل، لا تثبت إمكانية الوصول إلى بيانات اعتماد أن المهاجم استخدمها. سجل الأصل والفترة الزمنية والأدلة وحدود اليقين، ثم دع مسؤول الحادث يحدد الاحتواء المناسب للمخاطر. ينتج عن ذلك قرار أنفع من إعلان سلامة مؤسسة كاملة أو اختراقها اعتمادًا على نتيجة بحث واحدة باستخدام grep.

asset_id | workflow_run | install_time_utc
package_name | package_version | package_digest
script_policy | execution_evidence | network_evidence
identity | credential_scope | credential_lifetime
artifact_digest | downstream_destination
containment | credential_revocation | rebuild_evidence

التعافي يحتاج إلى أدلة تخص الأجهزة والهويات ومخرجات البناء

توصي Microsoft بفحص نشاط التثبيت المتأثر وتغيير بيانات الاعتماد التي كانت متاحة للأنظمة المخترقة. [2] تعالج إزالة الاعتمادية حالة الحزم؛ لكنها لا تلغي رمز وصول مسروقًا ولا تثبت سلامة جهاز التنفيذ. نسق الاحتواء وحفظ الأدلة، وألغِ الوصول المعرض للخطر من بيئة موثوقة، وأعد إنشاء بيئات التنفيذ المتأثرة انطلاقًا من أساس موثوق حيث يستلزم التحقيق ذلك.

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

ضع إجراء حماية عند كل انتقال للثقة

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

توصي إرشادات Google لسلسلة التوريد بطبقات حماية تشمل أجهزة تنفيذ معزولة، وقيودًا على سكربتات دورة حياة الحزم، وهويات قصيرة العمر لأحمال العمل. [5] راجع الإعدادات الافتراضية لنسخة مدير الحزم المستخدمة فعليًا؛ ولا تفترض أن جميع النسخ تشغّل السكربتات أو تمنعها بالطريقة نفسها. اسمح صراحة بآليات البناء الضرورية، وقلل بيانات الاعتماد في مهام التثبيت، وقيد الاتصالات الصادرة، واختبر أن الآلية المحظورة لا تستطيع التنفيذ بالفعل. لا يُعد الإعداد حدًا أمنيًا إلا بعد التحقق من سلوكه.

أسئلة التعافي التي ينبغي لمالك المنتج طرحها

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

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