Attaque de la chaîne d'approvisionnement axios@1.14.1 : Que faire maintenant

En bref

Les 30 et 31 mars 2026, les versions 1.14.1 et 0.30.4 d'axios ont été compromises sur npm avec une dépendance malveillante déposant un cheval de Troie d'accès à distance (RAT) sur les machines infectées. Les deux versions ont été dépubliées. La version sûre est la 1.14.0. Si vous avez installé axios@1.14.1 ou 0.30.4, considérez la machine comme compromise et révoquez toutes les informations d'identification immédiatement.

Essayez Apidog dès aujourd'hui

Qu'est-ce qu'axios et pourquoi est-ce important

axios compte 100 millions de téléchargements hebdomadaires sur npm. C'est le client HTTP utilisé dans d'innombrables frameworks frontend, services backend Node.js et applications d'entreprise. Lorsqu'un package aussi fondamental est compromis, le rayon d'impact est énorme — les développeurs qui ont exécuté npm install dans une courte fenêtre de temps les 30 et 31 mars ont téléchargé un logiciel malveillant sur leurs machines sans le savoir.

Ce n'est pas un risque hypothétique de chaîne d'approvisionnement. Cela s'est produit, c'est confirmé, et la charge utile était sérieuse : un cheval de Troie d'accès à distance multi-étapes capable d'exécuter des commandes arbitraires, d'exfiltrer des données système et de persister sur les machines infectées.

Si votre équipe utilise axios, et que vous utilisez Apidog pour concevoir et tester vos intégrations de client HTTP, lisez ceci avant votre prochain déploiement.

Chronologie de l'attaque

30 mars 2026 — 23:59:12 UTC :
Un package malveillant nommé plain-crypto-js@4.2.1 est publié sur npm par un compte utilisant [e-mail]. Une version antérieure propre (4.2.0) avait été publiée 18 heures auparavant, en tant que typosquat convaincant de la bibliothèque légitime crypto-js.

31 mars 2026 — 00:05:41 UTC :
La détection automatisée de logiciels malveillants de Socket signale plain-crypto-js@4.2.1 comme malveillant — six minutes après sa publication.

31 mars 2026 — peu après minuit :
axios@1.14.1 est publié sur npm, incluant plain-crypto-js@4.2.1 comme dépendance. Cette version n'apparaît pas dans les tags officiels du dépôt GitHub d'axios. Le tag légitime le plus récent reste v1.14.0.

31 mars 2026 — matin :
L'incident GitHub #10604 est ouvert, signalant que axios@1.14.1 et axios@0.30.4 sont compromis. Les mainteneurs d'Axios confirment qu'ils ne peuvent initialement pas révoquer l'accès de l'attaquant — le compte compromis a des permissions npm plus élevées que les mainteneurs légitimes.

31 mars 2026 :
Les versions axios@1.14.1 et axios@0.30.4 sont dépubliées de npm. Les mainteneurs d'Axios commencent à révoquer les jetons, à renforcer les contrôles de publication et à enquêter sur la compromission du jeton npm utilisé.

Comment l'attaque a fonctionné

L'attaque a exploité une faille dans le processus de publication d'axios : un jeton npm de longue durée utilisé via une publication de confiance. L'attaquant — probablement après avoir compromis les identifiants d'un mainteneur — a utilisé ce jeton pour publier une nouvelle version en dehors du flux normal.

La version malveillante a introduit plain-crypto-js@4.2.1 comme dépendance, package conçu pour ressembler à un utilitaire légitime. La version propre 4.2.0 avait été publiée juste avant pour réduire les soupçons.

À l'intérieur de plain-crypto-js@4.2.1, l'analyse de Socket a révélé une charge utile multi-étapes :

1. Exécution : Le package exécute du code au moment de l'installation (via des scripts de cycle de vie npm) pour déposer une charge utile secondaire.
2. Déploiement du RAT : La charge utile installe un cheval de Troie d'accès à distance qui ouvre une porte dérobée persistante.
3. Exfiltration : Le RAT peut exécuter des commandes shell arbitraires envoyées depuis un serveur C2, lire les variables d'environnement et les secrets du système de fichiers, et envoyer des données système sur le réseau.

Le RAT persiste après les redémarrages, donc la suppression du package npm ne suffit pas : il faut rechercher et supprimer explicitement le RAT.

Suis-je affecté ?

Vous êtes potentiellement affecté si :

• Vous avez exécuté npm install axios ou npm install (avec axios dans package.json) entre 30 mars, 23:59 UTC et 31 mars 2026 midi UTC.
• Votre node_modules/axios/package.json indique la version 1.14.1 ou 0.30.4.
• Votre package-lock.json ou yarn.lock référence axios en version 1.14.1 ou 0.30.4.

Vérifiez immédiatement :

# Vérifier la version installée
npm list axios

# Vérifier le fichier de lock
grep '"axios"' package-lock.json | head -5

# Vérifier la présence de plain-crypto-js
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFECTED" || echo "Not found"

Si plain-crypto-js est présent dans vos node_modules, vous avez exécuté la version malveillante.

Que faire maintenant

1. Mettez à jour axios immédiatement

npm install axios@1.14.0
# ou épinglez vers la version sûre la plus récente
npm install axios@latest

Vérifiez :

npm list axios
# Doit afficher 1.14.0 ou supérieur (dès qu'une 1.14.x clean est publiée)

2. Si vous avez installé la version compromise

Traitez la machine comme compromise :

• Révoquez tous les secrets accessibles depuis cette machine : clés API, identifiants DB, clés SSH, jetons cloud, variables .env.
• Vérifiez vos variables d'environnement — le RAT cible spécifiquement les secrets dans l'environnement de processus et le filesystem.
• Auditez les connexions réseau sortantes durant la période concernée — recherchez des connexions vers des IPs inconnues.
• Recherchez la persistance — vérifiez les tâches cron, scripts de démarrage et services systemd ajoutés autour de la fenêtre de compromission.
• Réinstallez l'image de la machine s'il s'agit d'un runner CI ou d'un serveur de production. Pour un ordinateur portable de développeur, considérez tous les identifiants comme compromis, révoquez tout avant de le remettre en service.

3. Auditez vos pipelines CI/CD

Si votre pipeline de build a exécuté npm install pendant la fenêtre à risque, votre environnement CI peut être compromis. Vérifiez :

# Parcourez les logs de build pour la période concernée
# Recherchez axios@1.14.1 dans toute sortie d'installation

# Vérifiez que les node_modules actuels du CI sont propres
npm list axios plain-crypto-js

Révoquez tous les secrets auxquels votre pipeline CI a accès : clés de déploiement, identifiants cloud, jetons de registre.

4. Vérifiez votre fichier de verrouillage

Les fichiers de lock (package-lock.json, yarn.lock) doivent épingler des versions exactes. Si votre fichier de lock contient 1.14.1, régénérez-le :

# Supprimez et régénérez
rm package-lock.json
npm install

Assurez-vous que le nouveau fichier de lock résout axios à une version sûre avant de le committer.

Utiliser Apidog pour auditer vos appels API axios

Si vous utilisez axios comme client HTTP pour appeler des API, Apidog peut vous aider à vérifier que votre intégration envoie toujours les bonnes requêtes après la mise à jour de la dépendance.

Après la mise à jour vers axios@1.14.0, importez vos endpoints API existants dans Apidog et effectuez une vérification de régression rapide pour confirmer l'absence de changements inattendus. Cela est particulièrement utile si vous craignez que la version malveillante ait altéré les charges utiles — les assertions de réponse d'Apidog permettent de valider les valeurs exactes, headers et codes d'état :

// Assertion post-réponse Apidog
pm.test("Response is clean — no injected fields", () => {
    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;
});

L'exécution de votre suite de tests complète avec la version à jour d'axios dans Apidog vous donne une base de référence propre avant de déployer.

Essayez Apidog gratuitement pour mettre en place vos tests de régression HTTP.

Pourquoi les attaques sur la chaîne d'approvisionnement npm sont difficiles à arrêter

L'attaque contre axios s'inscrit dans une tendance :

• event-stream (2018) : Un mainteneur malveillant a ajouté une charge utile ciblant les portefeuilles bitcoin. 8M de téléchargements hebdo.
• ua-parser-js (2021) : Compromis pour déposer un mineur de crypto et un voleur de mots de passe.
• node-ipc (2022) : Mainteneur a ajouté du code destructeur ciblant certains pays.
• xz utils (2024) : Porte dérobée introduite via une campagne d'ingénierie sociale sur deux ans.
• axios (2026) : Identifiants mainteneur compromis pour publier un RAT via une dépendance malveillante.

Le point commun : la confiance dans le compte de publication, pas dans le code. Si les identifiants d'un mainteneur sont compromis, l'attaquant peut publier du code malveillant.

Mesures d'atténuation réellement utiles :

Mesure	Ce qu'elle fait
Fichiers de verrouillage (package-lock.json)	Épingle les versions exactes, empêche les upgrades silencieuses
npm audit en CI	Signale les vulnérabilités connues avant le déploiement
Socket.dev / Snyk	Analyse comportementale — signale les packages suspects avant même un CVE
Authentification à deux facteurs sur npm	Rend la compromission des identifiants plus difficile
npm publish avec des jetons courts	Limite la fenêtre d'exposition si un jeton est divulgué
Lire les fichiers de lock dans les PR	Détecte des changements de dépendances inattendus à la relecture de code

L'équipe axios a reconnu que les jetons npm de longue durée ont facilité l'attaque et migre vers des contrôles de publication plus stricts. Mais une vraie solution doit venir de l'écosystème, pas seulement des projets individuels.

Indicateurs de Compromission (IOC)

Selon Socket :

• Packages malveillants : plain-crypto-js@4.2.1, axios@1.14.1, axios@0.30.4
• E-mail éditeur : [e-mail]
• Comportement : Connexions réseau à l'installation npm, persistance du RAT, exfiltration de variables d'environnement
• Versions axios sûres : 1.14.0 et inférieures (sauf 0.30.4), 1.13.x, 1.12.x

Si vous suspectez une infection, signalez à [e-mail] et conservez les logs.

Conclusion

La compromission d'axios 1.14.1 rappelle que la sécurité des dépendances est un processus continu, pas un audit ponctuel. Verrouillez vos versions, exécutez des outils d'analyse comportementale comme Socket en CI, révoquez les identifiants au moindre doute, et vérifiez vos fichiers de lock lors des reviews.

Pour rétablir la confiance dans votre intégration API après la mise à jour d'axios, Apidog vous offre scénarios de test, assertions et outils de simulation pour vérifier le comportement de votre client HTTP avant déploiement.

FAQ

Quelles versions d'axios sont compromises ?

axios@1.14.1 et axios@0.30.4. Les deux ont été dépubliées de npm. La version sûre est 1.14.0 (ou toute version 1.13.x, 1.12.x).

Que fait la charge utile malveillante d'axios ?

Elle intègre plain-crypto-js@4.2.1, qui déploie une charge utile multi-étapes comprenant un cheval de Troie d'accès à distance (RAT). Le RAT peut exécuter des commandes arbitraires depuis un C2 distant, exfiltrer des variables d'environnement et persister après redémarrage.

Comment savoir si j'ai installé la version compromise ?

Exécutez npm list axios — si cela indique 1.14.1 ou 0.30.4, vous êtes affecté. Vérifiez aussi npm list plain-crypto-js — si ce package est présent, le code malveillant a été exécuté sur votre machine.

Suffit-il de simplement mettre à jour axios ?

Non. La mise à jour supprime la dépendance malveillante pour l'avenir, mais le RAT peut déjà être installé et persister. Si vous avez installé la version compromise, révoquez tous les secrets et auditez la machine pour la persistance.

Comment l'attaquant a-t-il pu publier sur npm sans être un mainteneur ?

L'attaquant a probablement compromis les identifiants d'un mainteneur et exploité un jeton npm de longue durée ayant les droits de publication. L'équipe axios enquête et renforce les contrôles.

Quelle est la différence entre ceci et une vulnérabilité ordinaire ?

Une vulnérabilité est un défaut dans du code légitime. Une attaque de chaîne d'approvisionnement introduit un code malveillant via un canal de publication de confiance. Le code compromis n'a jamais été sur GitHub axios — il a été injecté directement dans la publication npm.

Comment puis-je protéger mes projets contre de futures attaques de chaîne d'approvisionnement ?

Utilisez des fichiers de verrouillage, exécutez npm audit en CI, ajoutez un outil comme Socket.dev pour l'analyse comportementale, activez l'authentification à deux facteurs sur npm, utilisez des jetons de publication courts et auditez les différences de vos fichiers de lock lors des revues de code.