Blog

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

Ashley Innocent

Ashley Innocent

2 April 2026

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

Apidog pour les entreprises

Déploiement sur site

SSO & RBAC

Conforme SOC 2

Explorer Apidog Enterprise

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 qui dépose 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.

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.

Il ne s'agit pas d'un risque hypothétique de chaîne d'approvisionnement. Cela s'est produit, cela a été 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.

bouton

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 nrwise@proton.me. 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 publiquement 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 manière dont un jeton npm de longue durée a été exploité pour obtenir un accès de publication non autorisé.

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 qui avait été utilisé en conjonction avec 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 processus de publication normal.

La nouvelle version a introduit plain-crypto-js@4.2.1 comme dépendance. Le nom du package a été conçu pour ressembler à un utilitaire de cryptographie légitime ; la version 4.2.0 propre antérieure avait établi un bref historique 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. Étape 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. Étape 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. Étape 3 — Exfiltration : Le RAT est capable d'exécuter des commandes shell arbitraires envoyées depuis un serveur C2, de lire les variables d'environnement et les secrets du système de fichiers, et d'envoyer des données système sur le réseau.

Le RAT persiste après les redémarrages, ce qui signifie que les machines ayant installé la version compromise restent à risque même après la suppression du package npm, à moins que le RAT ne soit explicitement recherché et supprimé.

Suis-je affecté ?

Vous êtes potentiellement affecté si :

Vérifiez immédiatement :

# Check installed version
npm list axios

# Check lock file
grep '"axios"' package-lock.json | head -5

# Check for plain-crypto-js presence
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
# or pin to latest safe
npm install axios@latest

Vérifiez :

npm list axios
# Should show 1.14.0 or higher (once a clean 1.14.x is published)

2. Si vous avez installé la version compromise

Ne traitez pas cela comme une mise à jour de dépendance de routine. Considérez la machine comme compromise :

3. Auditez vos pipelines CI/CD

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

# Check build logs for the affected timeframe
# Look for axios@1.14.1 in any install output

# Verify current CI node_modules are clean
npm list axios plain-crypto-js

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

4. Vérifiez votre fichier de verrouillage

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

# Remove and regenerate
rm package-lock.json
npm install

Vérifiez que le nouveau fichier de verrouillage résout axios à une version sûre avant de le commettre.

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 points de terminaison API existants dans Apidog et effectuez une vérification de régression rapide pour confirmer que le comportement n'a pas changé. Cela est particulièrement utile si vous craignez que la version malveillante n'ait altéré les charges utiles de requête ou de réponse — les assertions de réponse d'Apidog vous permettent de valider les valeurs de champs exactes, les en-têtes et les codes d'état :

// Apidog post-response assertion
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 mise à jour d'axios dans Apidog vous donne une base de référence propre documentée avant de déployer en production.

Essayez Apidog gratuitement pour configurer des tests de régression de client HTTP.

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

L'attaque contre axios n'est pas une anomalie. C'est un schéma récurrent :

Le fil conducteur commun : la confiance dans le compte de publication, et non dans le code. Le modèle de npm accorde l'accès à la publication aux mainteneurs, et si les identifiants d'un mainteneur sont compromis, l'attaquant hérite de cette confiance.

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 mises à niveau 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 l'existence de CVE
Authentification à deux facteurs sur npm Rend la compromission des identifiants plus difficile
npm publish avec des jetons de courte durée Limite la fenêtre d'exposition si un jeton est divulgué
Lire les fichiers de verrouillage dans les PR Détecte les changements de dépendances inattendus lors de la revue de code

L'équipe axios a depuis reconnu que les jetons npm de longue durée faisaient partie du problème et s'oriente vers des contrôles de publication plus stricts. Mais la solution doit venir de l'écosystème, et pas seulement des packages individuels.

Indicateurs de Compromission (IOC)

Selon l'analyse de Socket :

Si vous suspectez une infection, déposez un rapport auprès de l'équipe de sécurité de npm à security@npmjs.com et conservez les journaux.

Conclusion

La compromission d'axios 1.14.1 est un rappel que la sécurité des dépendances n'est pas un audit ponctuel, mais un processus continu. Verrouillez vos versions, exécutez des outils d'analyse comportementale comme Socket dans votre CI, révoquez les identifiants si quelque chose semble anormal, et examinez vos fichiers de verrouillage lors des revues de code.

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

bouton

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 des branches 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 serveur C2 distant, exfiltrer des variables d'environnement et des secrets, et persister après les redémarrages.

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 également 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 sur la machine. Si vous avez installé la version compromise, révoquez tous les secrets et auditez la machine pour les mécanismes de 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 qui avait des droits de publication. L'équipe axios enquête et renforce les contrôles de publication.

Quelle est la différence entre ceci et une vulnérabilité ordinaire ?Une vulnérabilité est un défaut dans un 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é dans le dépôt GitHub d'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 les comptes npm, utilisez des jetons de publication de courte durée et auditez les différences de vos fichiers de verrouillage lors des revues de code.

Pratiquez le Design-first d'API dans Apidog

Découvrez une manière plus simple de créer et utiliser des API

S'inscrire gratuitementTélécharger
Attaque de la chaîne d'approvisionnement axios@1.14.1 : Que faire maintenant