Dans la nuit du 30 au 31 mars 2026, axios a été compromis. 100 millions de téléchargements hebdomadaires, présent dans ~80 % des environnements cloud. Pendant trois heures, chaque npm install axios pouvait déployer un backdoor.

C'est l'une des attaques de supply chain les plus significatives de ces dernières années sur l'écosystème JavaScript. Voici ce qui s'est passé, comment ça a fonctionné, et ce que vous devez faire.

Ce qui s'est passé

Les attaquants ont compromis le compte npm de @jasonsaayman, l'un des mainteneurs principaux d'axios. La méthode : un changement de l'adresse e-mail du compte vers une adresse ProtonMail sous leur contrôle (ifstap@proton.me). Résultat — droits de publication complets sur le package.

Mais au lieu de modifier directement le code source d'axios (trop visible, trop facilement détectable par diff), ils ont utilisé une technique plus subtile : l'empoisonnement de dépendance indirecte.

L'attaque en trois étapes

Étape 1 — Pré-staging (18 heures avant l'attaque)

Les attaquants publient plain-crypto-js@4.2.0, un package vide et inoffensif. L'objectif : lui donner un minimum d'historique sur le registre npm, le faire paraître légitime.

Étape 2 — Injection du payload

Ils publient plain-crypto-js@4.2.1, cette fois avec le vrai payload malveillant intégré.

Étape 3 — Déclenchement via axios

Avec le compte @jasonsaayman en main, ils publient deux nouvelles versions d'axios qui déclarent plain-crypto-js@4.2.1 comme dépendance runtime :

• axios@1.14.1 (branche 1.x)
• axios@0.30.4 (branche 0.x legacy)

À partir de ce moment, n'importe quel npm install axios@1.14.1 télécharge aussi plain-crypto-js@4.2.1 et exécute automatiquement son hook postinstall.

Le payload : un RAT multiplateforme

Le script setup.js exécuté au postinstall fonctionne en deux phases.

Phase 1 — Dropper

Le dropper est doublement obfusqué. Il détecte l'OS cible (Windows, macOS, Linux), puis contacte le serveur C2 sfrclak.com:8000 (IP : 142.11.206.73) pour télécharger un payload de seconde phase adapté à la plateforme.

Phase 2 — WAVESHAPER.V2

Le backdoor déposé est identifié comme WAVESHAPER.V2, un RAT (Remote Access Trojan) multiplateforme. Une fois installé, il envoie un signal au C2 toutes les 60 secondes et est capable d'exécuter des commandes arbitraires ou des payloads supplémentaires.

Selon l'OS, les artefacts sont déposés ici :

OS	Chemin
macOS	/Library/Caches/com.apple.act.mond
Windows	%PROGRAMDATA%\wt.exe
Linux	/tmp/ld.py

Détection et fenêtre d'exposition

Les deux versions malveillantes ont été publiées dans une fenêtre de 39 minutes, et retirées environ 3 heures après leur première apparition (entre ~00:21 et ~03:29 UTC le 31 mars 2026).

La détection s'est faite quasi simultanément par plusieurs équipes de sécurité : Elastic Security Labs, StepSecurity, Aikido Security, Socket.dev, Snyk et Wiz, via leurs systèmes de monitoring de supply chain. L'issue GitHub axios/axios#10604 a centralisé les signalements publics.

Malgré la rapidité de la réponse, au moins 135 endpoints ont été observés en contact avec le serveur C2 dans la seule base partenaire de Huntress. Le taux d'exécution estimé dans les environnements exposés avoisine les 3 %.

Attribution : la Corée du Nord

Le Google Threat Intelligence Group (GTIG) attribue l'attaque au groupe UNC1069, un acteur lié à la Corée du Nord actif depuis au moins 2018, connu pour cibler les entreprises crypto et DeFi. L'utilisation de WAVESHAPER.V2 — version évoluée d'un backdoor déjà associé à ce groupe — est l'indicateur clé d'attribution.

Êtes-vous concerné ?

Vérifiez votre package-lock.json :

# Rechercher les versions compromises d'axios
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# Rechercher la dépendance malveillante
grep "plain-crypto-js" package-lock.json

Si vous trouvez plain-crypto-js dans votre lockfile, considérez l'environnement comme compromis — ne vous contentez pas de downgrader.

Remédiation

Si vous n'êtes pas compromis — mise à jour préventive

# Branche 1.x
npm install axios@1.14.0

# Branche 0.x (legacy)
npm install axios@0.30.3

Ajoutez un override dans votre package.json pour verrouiller la résolution transitive :

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

Si plain-crypto-js est présent dans votre environnement

Ne vous contentez pas de supprimer le package. La compromission est à traiter comme un incident de sécurité complet :

1. Revertez l'environnement sur un snapshot sain antérieur à l'incident
2. Rotez tous les secrets : clés API, tokens, mots de passe BDD, clés SSH, variables d'environnement
3. Vérifiez les artefacts de persistance aux chemins listés plus haut
4. Redéployez depuis un build propre avec des dépendances vérifiées

Ce que cette attaque révèle

Ce n'est pas une faille dans axios lui-même. C'est une faille dans la confiance implicite du modèle npm :

• Le hook postinstall s'exécute automatiquement, sans confirmation, avec les droits de l'utilisateur courant
• Un seul compte mainteneur compromis suffit à empoisonner un package utilisé 100 millions de fois par semaine
• La technique de pré-staging (publier une version propre avant la malveillante) est conçue pour tromper les systèmes de détection basés sur l'historique

L'écosystème npm repose sur la confiance dans les comptes individuels de mainteneurs. Sans 2FA obligatoire, sans signature cryptographique des packages, cette surface d'attaque reste exposée.

À retenir pour vos projets

• Verrouillez vos versions dans package-lock.json et ne faites pas npm install en aveugle en CI sans vérification du lockfile
• Activez les alertes de sécurité Dependabot ou Snyk sur vos dépôts — elles ont remonté cet incident en quelques heures
• MFA obligatoire sur tous les comptes npm qui publient des packages — c'est la mesure la plus simple qui aurait pu éviter cet incident
• Auditez régulièrement vos dépendances transitives, pas seulement directes

La fenêtre de trois heures et la réactivité de la communauté ont limité les dégâts. La prochaine attaque de ce type sera peut-être plus discrète.