En bref

  • Le compte npm du mainteneur principal d'Axios a été compromis, injectant un cheval de Troie dans deux versions du package.
  • Avec plus de 100 millions de téléchargements hebdomadaires, cette attaque supply chain touche potentiellement des milliers de projets JavaScript.
  • Les développeurs utilisant les versions 1.14.1 ou 0.30.4 doivent immédiatement rétrograder et effectuer une rotation de leurs secrets.

Ce qui s'est passé

Des attaquants ont compromis le compte npm de Jason Saayman, mainteneur principal de la librairie Axios, un client HTTP JavaScript utilisé par plus de 100 millions de projets chaque semaine. L'adresse email du compte a été modifiée vers une adresse Proton Mail, permettant aux pirates de publier deux versions malveillantes du package : axios@1.14.1 à 00h21 UTC et axios@0.30.4 moins d'une heure plus tard, selon BleepingComputer et The Hacker News.

Le mécanisme d'attaque repose sur l'injection d'une dépendance malveillante nommée plain-crypto-js dans le fichier package.json. Cette dépendance exécute un script post-installation qui lance un dropper obfusqué. Ce dernier contacte un serveur de commande et contrôle (C2) pour télécharger un payload adapté au système d'exploitation détecté — Windows, Linux ou macOS — déployant ainsi un RAT (Remote Access Trojan) multiplateforme.

L'attaque a été rapidement identifiée et les versions malveillantes retirées de npm. Toutefois, le délai entre la publication et le retrait a suffi pour que de nombreux systèmes CI/CD et environnements de développement récupèrent automatiquement les versions compromises. Cette technique rappelle d'autres attaques supply chain récentes sur l'écosystème npm, comme celle documentée dans notre analyse de Shai-Hulud 2.

Pourquoi c'est important

Axios est l'une des librairies les plus utilisées de l'écosystème JavaScript. Sa compromission illustre la fragilité structurelle de la chaîne d'approvisionnement logicielle : un seul compte mainteneur sans authentification multi-facteurs suffisante peut mettre en péril des millions de projets. Contrairement aux attaques par typosquatting, cette compromission touche le package légitime lui-même, ce qui la rend particulièrement dangereuse car les outils de vérification de dépendances n'émettent aucune alerte.

Pour les entreprises, l'impact est double. D'une part, le RAT déployé peut exfiltrer des clés API, des tokens d'authentification et des variables d'environnement sensibles. D'autre part, la contamination se propage silencieusement via les pipelines CI/CD qui installent automatiquement les dernières versions mineures. Les organisations qui n'utilisent pas de fichier lockfile strict ou de registre miroir sont les plus exposées, comme le détaille notre guide sur la détection des dépendances malveillantes.

Ce qu'il faut retenir

  • Vérifiez immédiatement si vos projets utilisent axios@1.14.1 ou axios@0.30.4 et rétrogradez vers 1.14.0 ou 0.30.3.
  • Effectuez une rotation complète des secrets (clés API, tokens, credentials) sur tout système ayant installé une version compromise.
  • Adoptez des lockfiles stricts (package-lock.json, yarn.lock) et envisagez un registre npm miroir avec validation des checksums pour protéger votre chaîne d'approvisionnement.
  • Activez l'authentification multi-facteurs sur tous vos comptes de registres de packages, comme recommandé dans les bonnes pratiques supply chain.

Comment savoir si mon projet a été affecté par la compromission d'Axios ?

Vérifiez votre fichier package-lock.json ou yarn.lock pour les versions 1.14.1 ou 0.30.4 d'Axios. Recherchez également la présence de la dépendance plain-crypto-js dans votre arborescence node_modules. Si vous trouvez l'une de ces versions, considérez le système comme compromis : rétrogradez immédiatement, purgez le cache npm, et effectuez une rotation de tous les secrets accessibles depuis l'environnement affecté.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact