Blog

Comprendre l'attaque de la chaîne d'approvisionnement NPM Axios et protéger vos projets API

Ashley Innocent

Ashley Innocent

1 April 2026

Comprendre l'attaque de la chaîne d'approvisionnement NPM Axios et protéger vos projets API

Apidog pour les entreprises

Déploiement sur site

SSO & RBAC

Conforme SOC 2

Explorer Apidog Enterprise

En bref

Le 31 mars 2026, des attaquants ont compromis le compte npm du mainteneur principal d'Axios, le client HTTP JavaScript le plus populaire avec 83 millions de téléchargements hebdomadaires. Ils ont publié des versions malveillantes (1.14.1 et 0.30.4) contenant un RAT (cheval de Troie d'accès à distance) multiplateforme qui dérobe les identifiants, les clés SSH et les jetons cloud des machines de développeurs. Rétrogradez immédiatement vers Axios 1.14.0, faites pivoter tous les secrets et recherchez les indicateurs de compromission sur votre système.

Introduction

Axios traite plus de requêtes HTTP que toute autre bibliothèque JavaScript. Si vous avez créé un client API, testé des points de terminaison ou connecté un frontal à un dorsal au cours des cinq dernières années, vous l'avez probablement utilisé.

Le 31 mars 2026, à 00h21 UTC, un acteur de la menace a publié la version 1.14.1 d'Axios via un compte de mainteneur piraté. Le package semblait identique à la version légitime. La différence était chirurgicale : seul le fichier package.json avait changé parmi les 86 fichiers. Mais ce seul fichier a injecté une dépendance fantôme appelée plain-crypto-js qui a déployé un cheval de Troie d'accès à distance sur chaque machine exécutant npm install.

Les versions malveillantes sont restées actives pendant environ deux à trois heures avant que npm ne les retire. Deux à trois heures sur 83 millions de téléchargements hebdomadaires.

💡
Si vous créez ou testez des API, cette attaque a directement ciblé votre chaîne d'outils. Le client HTTP intégré d'Apidog élimine le besoin de bibliothèques HTTP tierces dans votre flux de travail de test d'API, supprimant ainsi toute cette surface d'attaque. Téléchargez Apidog gratuitement pour suivre les étapes d'audit de sécurité ci-dessous.
button

Cet article explique comment l'attaque a fonctionné, comment détecter si vos systèmes sont compromis et ce que les équipes API devraient modifier dans leur gestion des dépendances à l'avenir.

Comment s'est déroulée l'attaque de la chaîne d'approvisionnement d'Axios

La chronologie

L'attaquant a exécuté cette opération avec précision sur une période de 18 heures :

Comment le compte a été compromis

L'attaquant a pris le contrôle du compte npm jasonsaayman, le mainteneur principal d'Axios. Il a modifié l'adresse e-mail enregistrée pour ifstap@proton.me. Les preuves médico-légales clés :

Cette distinction est importante. Si votre organisation publie des packages npm, l'absence de liaison OIDC et de provenance CI/CD sur une version est un signal d'alarme qui mérite d'être automatisé.

La technique d'injection de dépendances

Voici ce qui a rendu cette attaque subtile. L'attaquant n'a pas modifié le code source d'Axios. Il a modifié une ligne dans package.json pour ajouter plain-crypto-js@^4.2.1 comme dépendance d'exécution. Ce paquet n'a jamais été importé nulle part dans la base de code d'Axios. Il existait uniquement pour déclencher son hook postinstall lors de l'exécution de npm install.

L'analyse binaire a confirmé la précision chirurgicale : seul package.json différait entre la version propre 1.14.0 et la version compromise 1.14.1 sur les 86 fichiers du paquet.

Ce que fait la charge utile malveillante

Le mécanisme du dropper

Le hook postinstall dans plain-crypto-js a exécuté un fichier obfusqué de 4,2 Ko appelé setup.js. Il utilisait deux couches d'obfuscation :

  1. Couche 1 : Chiffrement XOR utilisant une clé dérivée de la chaîne "OrDeR_7077"
  2. Couche 2 : Encodage Base64 avec inversion de caractères

Une fois décodé, le dropper a identifié le système d'exploitation hôte et a exécuté des charges utiles spécifiques à la plateforme.

Voies d'attaque spécifiques à la plateforme

macOS:

Écrit un AppleScript dans /tmp/6202033
Exécute via osascript
Télécharge la charge utile dans /Library/Caches/com.apple.act.mond

Windows:

Copie PowerShell dans %PROGRAMDATA%\wt.exe (artefact de persistance)
Exécute le dropper VBScript via cscript

Linux:

Télécharge le RAT Python dans /tmp/ld.py
Exécute via nohup python3

Les trois branches ont contacté un serveur de commande et contrôle avec des corps de POST spécifiques à la plateforme :

Capacités du RAT

Le cheval de Troie d'accès à distance déployé prend en charge :

En termes simples : l'attaquant obtient un contrôle à distance total de votre machine de développement. Il peut lire vos fichiers .env, voler vos clés API, copier vos clés SSH et collecter les jetons de votre fournisseur cloud.

Anti-forensics : la charge utile auto-nettoyante

Après exécution, le dropper a effectué trois étapes de nettoyage :

  1. Suppression de setup.js lui-même
  2. Suppression du package.json malveillant
  3. Renommage d'un package.md pré-établi (signalant la version 4.2.0) en package.json

Cela a créé une couche de tromperie où npm list rapporterait la version 4.2.0 au lieu de la 4.2.1 qui avait exécuté la charge utile. Un développeur vérifiant ses dépendances après les faits ne verrait rien d'anormal.

Qui est derrière cette attaque

Le Google Threat Intelligence Group a attribué l'attaque Axios à UNC1069, un acteur de la menace présumé nord-coréen. Le logiciel malveillant macOS présente un "chevauchement significatif" avec WAVESHAPER, une porte dérobée C++ suivie par Mandiant en février 2026.

Les groupes nord-coréens parrainés par l'État ont une grande expérience des attaques de la chaîne d'approvisionnement. Ils ont historiquement utilisé des outils de développement compromis pour voler des cryptomonnaies, et cette opération suit le même plan : compromettre un outil de développement largement utilisé pour accéder aux identifiants et à l'infrastructure cloud de milliers d'organisations.

Le niveau de sophistication est remarquable. L'injection de dépendances en deux étapes, le déploiement de RAT multiplateforme et le nettoyage anti-forensic pointent tous vers une opération bien financée. Il ne s'agit pas d'un script kiddie qui dépose un cryptomineur. C'est une opération de renseignement ciblant les postes de travail des développeurs.

Comment vérifier si vous êtes affecté

Étape 1 : Vérifiez votre version d'Axios

Exécutez ceci dans chaque projet utilisant Axios :

npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"

Si cela renvoie des résultats, votre projet a installé une version compromise.

Étape 2 : Vérifiez la dépendance malveillante

ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENTIELLEMENT AFFECTÉ"

Même si le dropper s'est nettoyé, l'existence du répertoire confirme que la charge utile a été exécutée.

Étape 3 : Recherchez les artefacts RAT sur votre système

macOS:

ls -la /Library/Caches/com.apple.act.mond 2>/dev/null

Linux:

ls -la /tmp/ld.py 2>/dev/null

Windows (PowerShell):

Test-Path "$env:PROGRAMDATA\wt.exe"

Étape 4 : Vérifiez les indicateurs réseau

Bloquez et recherchez les connexions vers :

Étape 5 : Vérifiez les journaux de build CI/CD

Examinez toutes les exécutions de pipeline CI/CD entre le 31 mars 00h21 UTC et 03h15 UTC. Toute exécution de npm install ou npm ci pendant cette fenêtre qui a résolu Axios aurait pu exécuter le dropper dans votre environnement de build.

Mesures de remédiation immédiates

Si vous trouvez des indicateurs de compromission, considérez le système affecté comme entièrement compromis. Voici la liste des priorités :

1. Rétrogradez immédiatement Axios

npm install axios@1.14.0

Ou pour la branche 0.x :

npm install axios@0.30.3

2. Ajoutez des remplacements de version à votre package.json

Empêchez la résolution transitive vers les versions malveillantes :

{
  "overrides": {
    "axios": "1.14.0"
  }
}

Pour Yarn :

{
  "resolutions": {
    "axios": "1.14.0"
  }
}

3. Supprimez le package malveillant

rm -rf node_modules/plain-crypto-js

4. Faites pivoter toutes les informations d'identification

Si le dropper s'est exécuté sur votre machine, supposez que les éléments suivants sont compromis :

Faites pivoter tout. Il n'y a aucun moyen de savoir ce que le RAT a exfiltré pendant sa fenêtre active.

5. Bloquez le C2 au niveau du réseau

Ajoutez à votre fichier hosts ou à vos règles de pare-feu :

echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts

6. Si des artefacts sont trouvés, reconstruisez la machine

Un RAT avec exécution de shell et accès au système de fichiers peut modifier n'importe quoi. Si vous avez trouvé des artefacts de l'étape 3, ne faites pas confiance au système. Reconstruisez à partir d'un état sain connu.

Défenses à long terme pour les équipes de développement d'API

Utilisez des lockfiles et épinglez des versions exactes

L'attaque d'Axios a exploité les plages semver ^. Si votre package.json indique "axios": "^1.14.0", npm résout la dernière version compatible, qui était 1.14.1 pendant la fenêtre d'attaque.

{
  "dependencies": {
    "axios": "1.14.0"
  }
}

Épinglez des versions exactes. Engagez toujours votre package-lock.json ou yarn.lock. Exécutez npm ci au lieu de npm install dans CI/CD pour forcer la résolution des lockfiles.

Désactiver les scripts postinstall dans CI/CD

L'attaque entière dépendait de l'exécution des hooks postinstall lors de npm install. Vous pouvez désactiver cela :

npm ci --ignore-scripts

Cela brise certains packages qui nécessitent une compilation native. Testez d'abord vos builds, puis autorisez sélectivement les scripts pour les packages qui en ont besoin en utilisant .npmrc :

ignore-scripts=true

Auditez régulièrement les dépendances

npm audit
npx socket-security/cli audit

Exécutez ces commandes en CI/CD comme une porte. Toute vulnérabilité critique ou élevée devrait bloquer la compilation.

Réduisez votre surface de dépendance client HTTP

Voici la question plus profonde que cette attaque soulève : pourquoi votre flux de travail de test d'API dépend-il d'une bibliothèque HTTP tierce qui peut être compromise ?

Apidog fournit un client HTTP intégré pour les tests, le débogage et la documentation API. Vous n'avez pas besoin d'Axios, de node-fetch ou de got dans votre pile de test. Le client HTTP fait partie de la plateforme, sans aucune dépendance tierce à compromettre.

Pour les tests d'API spécifiquement, le déplacement de vos requêtes HTTP dans Apidog élimine toute la surface d'attaque :

Essayez Apidog gratuitement pour voir comment la suppression des dépendances de bibliothèque HTTP de votre flux de travail API réduit votre risque de chaîne d'approvisionnement.

Vérifiez la provenance des paquets

npm prend désormais en charge la provenance des paquets via Sigstore. Vérifiez si les paquets dont vous dépendez l'utilisent :

npm audit signatures

Les versions malveillantes d'Axios n'avaient pas de provenance OIDC. Les versions légitimes des pipelines CI/CD incluent une attestation cryptographique de leur origine de build. Si une nouvelle version apparaît sans provenance, traitez-la avec suspicion.

Ce que cela signifie pour l'écosystème JavaScript

Le modèle de confiance est rompu

Le modèle de confiance de npm dépend de la sécurité du compte du mainteneur. Un seul identifiant compromis donne à un attaquant le contrôle d'un paquet que 83 millions de projets installent chaque semaine. L'authentification à deux facteurs aide, mais des jetons d'accès de longue durée peuvent toujours être volés dans des environnements de développement compromis.

La communauté discute de plusieurs changements structurels :

Les attaques de la chaîne d'approvisionnement ne ralentissent pas

Cette attaque a eu lieu quelques jours après l'incident de la fracture de RubyGems et les préoccupations continues concernant les dépendances PyPI. Les registres de paquets de tous les écosystèmes linguistiques sont sous attaque soutenue. Les développeurs d'API doivent considérer leur arbre de dépendances comme une surface d'attaque, et non comme une commodité.

La discussion sur Reddit a bien capturé le sentiment : "NPM est la plus grande faiblesse d'Internet aujourd'hui et cela causera encore une catastrophe géante." Que vous soyez d'accord ou non avec l'hyperbole, l'attaque d'Axios démontre que l'ampleur des dégâts est réelle.

Comparaison : approches de dépendances de clients HTTP

Approche Risque de la chaîne d'approvisionnement Charge de maintenance Capacité de test
Axios + scripts personnalisés Élevé (dépendance tierce) Élevé (gestion des versions) Configuration manuelle requise
Node.js native fetch Faible (intégré au runtime) Faible Fonctionnalités de test limitées
Client intégré Apidog Aucun (pas de dépendance npm) Aucun (géré par la plateforme) Tests complets, mocking, documentation
Scripts curl/httpie Faible (outil au niveau du système) Moyen Automatisation limitée

FAQ

Axios est-il sûr à utiliser maintenant ?

Oui. Les versions 1.14.0 et 0.30.3 sont propres. Les versions compromises (1.14.1 et 0.30.4) ont été dépubliées en environ trois heures. Vérifiez votre version installée avec npm list axios et examinez votre lockfile pour confirmer que vous utilisez une version sûre.

Comment savoir si le RAT s'est exécuté sur ma machine ?

Vérifiez la présence d'artefacts spécifiques à la plateforme : /Library/Caches/com.apple.act.mond sur macOS, /tmp/ld.py sur Linux, ou %PROGRAMDATA%\wt.exe sur Windows. Vérifiez également si node_modules/plain-crypto-js existe dans l'un de vos projets. Le dropper se nettoie après exécution, donc l'absence d'artefacts ne garantit pas votre sécurité si vous avez installé la version compromise.

Dois-je arrêter complètement d'utiliser Axios ?

Pas nécessairement. Axios reste une bibliothèque bien maintenue avec un solide historique. Mais cette attaque devrait vous inciter à évaluer si vous avez réellement besoin d'un client HTTP tiers. Node.js 18+ inclut un fetch natif. Pour les tests d'API, des plateformes comme Apidog fournissent des clients HTTP intégrés qui éliminent cette dépendance.

Comment puis-je prévenir les attaques de la chaîne d'approvisionnement dans mes projets ?

Épinglez les versions exactes des dépendances, engagez les fichiers de verrouillage (lockfiles), exécutez npm ci --ignore-scripts en CI/CD, auditez régulièrement les dépendances, vérifiez la provenance des paquets avec npm audit signatures et minimisez votre arbre de dépendances. Envisagez de déplacer les workflows de test d'API vers des plateformes intégrées qui ne dépendent pas des paquets npm pour la communication HTTP.

Cette attaque était-elle liée à la fuite du code source de Claude ?

Les deux événements se sont produits le même jour (31 mars 2026), mais ils ne sont pas liés. L'attaque d'Axios était une compromission délibérée de la chaîne d'approvisionnement par un acteur de la menace parrainé par l'État. La fuite du code de Claude a résulté d'un bug de l'outil de build Bun qui a livré des "source maps" en production. Le timing coïncident a alimenté la discussion sur la sécurité du registre npm en général.

Qui était derrière l'attaque d'Axios ?

Le Google Threat Intelligence Group a attribué l'attaque à UNC1069, un acteur de la menace présumé nord-coréen. Le logiciel malveillant macOS présente un chevauchement significatif avec WAVESHAPER, une porte dérobée suivie par Mandiant. Les groupes nord-coréens ont une vaste expérience des attaques de la chaîne d'approvisionnement, ciblant généralement les identifiants de développeurs et l'infrastructure de cryptomonnaie.

Combien de développeurs ont été affectés ?

Les versions malveillantes ont été actives pendant environ deux à trois heures. Avec 83 millions de téléchargements hebdomadaires, l'exposition potentielle est significative. npm n'a pas publié de chiffres officiels d'impact. La détection runtime de StepSecurity a confirmé que le dropper a contacté le C2 dans les 1,1 seconde après le démarrage de npm install, avant que la résolution des dépendances ne soit complète.

Apidog peut-il aider à prévenir les attaques de la chaîne d'approvisionnement ?

Apidog élimine un vecteur d'attaque majeur en fournissant un client HTTP intégré pour les tests, le débogage et la documentation API. Vous n'avez pas besoin d'installer Axios, node-fetch ou d'autres bibliothèques HTTP dans votre workflow de test. Cela réduit votre surface de dépendance npm et élimine le risque que des packages clients HTTP compromis affectent votre processus de développement API.

Points clés à retenir

L'attaque d'Axios est un signal d'alarme. Chaque dépendance dans votre node_modules est une décision de confiance. Assurez-vous de prendre ces décisions délibérément, et non par défaut.

button

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
Comprendre l'attaque de la chaîne d'approvisionnement NPM Axios et protéger vos projets API