Attaque npm Axios : comment un compte de mainteneur piraté a menacé des millions de développeurs

8 min de lecture

Le 31 mars 2026, l’entreprise de cybersécurité StepSecurity a découvert un cheval de Troie d’accès à distance (RAT) dans deux versions piratées du paquet npm Axios – l’une des bibliothèques JavaScript les plus utilisées au monde, avec plus de 100 millions de téléchargements par semaine. L’attaque exploitait une dépendance falsifiée, un compte de mainteneur compromis et un serveur C2 pour installer des portes dérobées multiplateformes sur les machines des développeurs. Elle est considérée comme l’une des attaques par chaîne d’approvisionnement les plus sophistiquées de l’histoire de l’écosystème npm.

Ce qui s’est passé

Depuis plus de dix ans, Axios est l’une des bibliothèques JavaScript les plus populaires pour les requêtes HTTP. Bien que les environnements d’exécution modernes comme Node.js et Deno prennent désormais en charge l’API Fetch native, des millions de développeurs continuent de privilégier Axios pour son API plus conviviale, sa transformation automatique en JSON et ses intercepteurs intégrés. Cette popularité en a fait une cible idéale.

Le 30 mars 2026 à 23h59 UTC, un attaquant a publié la version 4.2.1 du paquet npm plain-crypto-js – un paquet ressemblant à s’y méprendre au légitime et largement utilisé crypto-js. Vingt-deux minutes plus tard, la version manipulée 1.14.1 d’Axios, taguée « latest », a suivi. À 01h00 UTC, la version 0.30.4, taguée « legacy », est également apparue. Les deux versions d’Axios intégraient plain-crypto-js comme nouvelle dépendance d’exécution.

L’attaque avait été soigneusement orchestrée. Dix-huit heures plus tôt, l’attaquant avait publié une version inoffensive 4.2.0 de plain-crypto-js – une version leurre qui n’a déclenché aucune alerte lors des scans automatisés. Ce n’est qu’avec la version 4.2.1 que le véritable code malveillant a été introduit.

Normalement, les versions d’Axios sont publiées via GitHub Actions. Les versions piratées, en revanche, ont été directement publiées via un compte npm compromis. L’attaquant avait pris le contrôle du compte du mainteneur principal, jasonsaayman, et remplacé l’adresse e-mail enregistrée par une adresse Proton Mail. À ce jour (avril 2026), les détails exacts de cette compromission restent non confirmés publiquement.

npm a retiré les deux versions en deux à trois heures environ. Pour un paquet comptant plus de 100 millions de téléchargements hebdomadaires, même quelques heures représentent une fenêtre critique.

Anatomie de l’attaque : du script postinstall au serveur C2

Le code source d’Axios lui-même ne contenait aucun code malveillant. La manipulation se limitait à l’ajout de plain-crypto-js comme dépendance dans le fichier package.json. Quiconque n’aurait audité que le code d’Axios n’aurait rien trouvé. L’arme véritable se cachait dans la nouvelle dépendance.

Le paquet plain-crypto-js contenait un script postinstall nommé setup.js. Dès qu’un développeur exécutait npm install, un JavaScript obscurci par un double chiffrement XOR s’exécutait en arrière-plan – ce qu’on appelle le RAT-Dropper. Celui-ci opérait en quatre phases :

Phase 1 – Identification du système : Le script identifie le système d’exploitation de la machine cible. Les systèmes supportés sont macOS, Windows et Linux.

Phase 2 – Téléchargement de la charge utile : Le dropper établit une connexion avec le serveur de commande et contrôle (domaine : sfrclak.com, IP : 142.11.206.73, port 8000). De là, un binaire spécifique à la plateforme est téléchargé.

Phase 3 – Exécution : Le RAT est écrit sur le disque dur et lancé. Sous macOS, il s’installe sous le nom com.apple.act.mond dans le cache de la bibliothèque et est exécuté via /bin/zsh. Sous Windows, il se fait passer pour wt.exe (Windows Terminal) dans %PROGRAMDATA% et utilise un dropper VBScript. Sous Linux, un RAT Python est téléchargé vers /tmp/ld.py et lancé en arrière-plan avec nohup.

Phase 4 – Effacement des traces : Le script postinstall s’auto-efface et remplace son propre fichier package.json par la version propre 4.2.0. Un npm list ultérieur affiche la version 4.2.0. Un npm audit ne détecte aucune anomalie. L’infection est active, mais invisible.

Une fois installé, le RAT a accès à tout ce qui se trouve sur le système compromis : identifiants AWS, clés API OpenAI, tokens GitHub, clés SSH, fichiers .env contenant des mots de passe de bases de données. Dans les environnements CI/CD, les conséquences peuvent être encore plus graves : on y trouve souvent des identifiants de déploiement, des clés de signature et l’accès aux systèmes de production. Un serveur de build compromis peut devenir la porte d’entrée pour toute l’infrastructure.

StepSecurity a découvert l’attaque grâce à son AI Package Analyst et à son outil de monitoring en temps réel Harden-Runner dans des pipelines GitHub Actions instrumentés. L’outil enregistre les connexions réseau sortantes pendant npm install et a déclenché une alerte lorsqu’un serveur C2 inconnu a été contacté.

« Le conseil de sécurité le plus important depuis des années : gardez vos paquets à jour. Depuis peu, on a l’impression que c’est justement le moyen le plus rapide de se faire compromettre. »
– Note de la rédaction

Pourquoi cette attaque marque un tournant

Les attaques sur la chaîne d’approvisionnement (supply-chain) ciblant npm ne sont pas nouvelles. L’incident event-stream de 2018 est resté inaperçu pendant des mois et visait les portefeuilles de cryptomonnaies. La compromission de ua-parser-js en 2021 a touché un paquet comptabilisant sept millions de téléchargements par semaine et a diffusé des voleurs de credentials. Le sabotage de colors.js en 2022 était une action de protestation politique menée par le mainteneur lui-même. Chacun de ces incidents a ébranlé l’écosystème – et pourtant, l’attaque contre Axios représente une escalade sans précédent.

L’ampleur de la cible est inédite : Axios figure parmi les dix paquets npm les plus utilisés. Le rayon d’impact (blast radius) d’une compromission réussie concerne potentiellement des centaines de milliers de projets et de pipelines CI/CD à travers le monde.

La sophistication dépasse largement celle des attaques précédentes. Au lieu d’injecter directement du code malveillant dans le code source, l’attaquant a utilisé une injection de dépendances étagée avec activation différée et effacement automatique des traces. Après l’installation, le système semblait propre – un camouflage actif qui va bien au-delà d’une simple dissimulation passive. StepSecurity a enregistré le premier contact avec un serveur C2 dans les deux secondes suivant un npm install sur un runner instrumenté – sans ce monitoring automatisé, l’attaque serait probablement restée inaperçue beaucoup plus longtemps.

La comparaison avec les incidents npm antérieurs met en lumière cette escalade : lors de l’attaque event-stream en 2018, un attaquant a pris le contrôle d’un paquet abandonné par ingénierie sociale et a placé du code malveillant pendant des mois, ciblant les portefeuilles Bitcoin. Avec ua-parser-js en 2021, le compte du mainteneur a été piraté et un voleur de credentials a été diffusé – comme dans le cas d’Axios, mais sans la dissimulation multi-niveaux ni les payloads multiplateformes. Le sabotage de colors.js en 2022 était une action de protestation délibérée du mainteneur, et non une compromission externe.

S’ajoute à cela la question de l’attribution : Microsoft Threat Intelligence attribue l’attaque au groupe Sapphire Sleet, tandis que Google Threat Intelligence Group l’associe au groupe UNC1069. Les deux dénominations renvoient à des acteurs nord-coréens motivés par des intérêts financiers. Elastic Security Labs a identifié des chevauchements entre le binaire macOS et WAVESHAPER, une backdoor nord-coréenne connue. Si cette classification se confirme, il s’agirait du premier cas documenté où un acteur étatique compromet un paquet npm parmi les 100 plus populaires.

Ce que les équipes IT doivent faire maintenant

La compromission ne concerne pas uniquement les développeurs JavaScript. Toute organisation utilisant Axios dans ses projets ou ses pipelines CI/CD doit prioriser les mesures suivantes :

1. Vérifier les versions : Examiner tous les fichiers package.json et les fichiers de verrouillage pour détecter axios@1.14.1 ou axios@0.30.4. Rétrograder immédiatement vers les versions 1.14.0 ou 0.30.3.
2. Analyser node_modules : Rechercher le paquet plain-crypto-js. S’il est présent : considérer le système comme compromis.
3. Vérifier les artefacts RAT : Sous macOS, rechercher /Library/Caches/com.apple.act.mond ; sous Windows, %PROGRAMDATA%/wt.exe ; sous Linux, /tmp/ld.py.
4. Renouveler les identifiants : Changer immédiatement toutes les clés API, tokens et informations d’identification sur les systèmes affectés – AWS, OpenAI, GitHub, fichiers .env.
5. Bloquer le C2 : Bloquer l’IP 142.11.206.73 et le domaine sfrclak.com au niveau du périmètre réseau.
6. Sécuriser la CI/CD : Adopter npm ci –ignore-scripts comme standard. Activer des politiques de délai minimal avant publication pour éviter l’installation automatique des versions fraîchement publiées.

La faille structurelle persiste

L’incident Axios révèle un problème fondamental de l’écosystème npm : un seul compte doté d’un token de publication valide peut diffuser du code malveillant sur des millions de systèmes. npm a progressé avec les *Trusted Publishers* et l’authentification basée sur OIDC – mais l’attaquant a contourné ce mécanisme en prenant le contrôle du compte du mainteneur.

Pour les RSSI et les équipes de sécurité IT, une priorité s’impose : la sécurité de la chaîne d’approvisionnement logicielle doit atteindre le même niveau d’importance que la sécurité réseau ou des terminaux. La surveillance automatisée des dépendances, l’analyse en temps réel dans les pipelines CI/CD et des politiques strictes pour les paquets tiers ne sont plus des options, mais des nécessités.

Concrètement, cela signifie que chaque organisation doit disposer d’une *Software Bill of Materials* (SBOM) à jour, d’alertes automatisées en cas de modifications inhabituelles des dépendances, et d’une politique claire définissant la vitesse à laquelle les nouvelles versions de paquets peuvent être déployées en production. L’utilisation systématique des fichiers de verrouillage, la désactivation par défaut des scripts *postinstall* dans les pipelines CI/CD et la configuration de politiques de délai minimal avant publication éliminent une grande partie de cette surface d’attaque. La prochaine attaque ne visera pas Axios – mais elle exploitera le même mécanisme.

Foire aux questions

Suis-je concerné si j’utilise Axios ?

Uniquement si vous avez installé la version 1.14.1 ou 0.30.4. Toutes les autres versions ne sont pas affectées. Vérifiez votre fichier package.json et vos fichiers de verrouillage (package-lock.json, yarn.lock, pnpm-lock.yaml).

Est-il suffisant de désinstaller la version compromise d’Axios ?

Non. Si le RAT a déjà été exécuté, il s’est copié dans les chemins système et a supprimé le script *postinstall*. Un simple rétrogradage d’Axios ne supprime pas le cheval de Troie. Considérez le système comme compromis et renouvelez tous les identifiants.

Comment le compte du mainteneur a-t-il été compromis ?

Le vecteur d’attaque exact n’est pas confirmé publiquement à ce jour (avril 2026). Il est établi que l’adresse e-mail enregistrée du compte npm jasonsaayman a été remplacée par une adresse Proton Mail et que les publications ont contourné le pipeline GitHub Actions habituel.

Existe-t-il un numéro CVE pour cet incident ?

À ce jour (avril 2026), aucune CVE n’a été attribuée. Plusieurs entreprises de cybersécurité ont documenté l’incident, mais l’attribution formelle d’une CVE reste en attente.

Pourquoi npm n’a-t-il pas détecté plus rapidement les versions malveillantes ?

npm n’effectue pas d’analyse comportementale automatisée lors de la publication. Les paquets sont principalement vérifiés à l’aide de signatures de malware connues. Un script *postinstall* contactant un serveur externe n’est pas techniquement inhabituel – de nombreux paquets légitimes utilisent des mécanismes similaires pour les étapes de configuration. La détection a été réalisée grâce à une surveillance externe, et non par les mécanismes de protection propres à npm.

Que puis-je faire pour limiter les attaques sur la chaîne d’approvisionnement en général ?

Utilisez systématiquement les fichiers de verrouillage, exécutez npm ci au lieu de npm install dans vos pipelines CI/CD, activez –ignore-scripts pour les paquets non fiables et misez sur des outils de surveillance en temps réel. Une politique de délai minimal avant publication empêche l’installation automatique des versions fraîchement publiées. En complément, les équipes devraient maintenir une *Software Bill of Materials* (SBOM) et configurer des alertes automatisées en cas de modifications des dépendances.

Source de l’image : générée par IA (mai 2026), certificat C2PA intégré à l’image

À propos de l'auteur: Benedikt Langer

Plus d'articles de Benedikt Langer