Compromission du paquet NPM axios (TOP 5 NPM)

Loïc Castel
il y a 2 heures
8 min de lecture

Fin mars 2026, plus exactement le 31 mars, le très populaire client HTTP JavaScript axios (dans le TOP5 des paquets les plus téléchargés) a été victime d’une attaque de supply chain sur npm, à la suite du détournement du compte d’un mainteneur principal et de la publication de deux versions malveillantes (1.14.1 et 0.30.4). Ces versions ajoutaient une dépendance cachée, plain-crypto-js@4.2.1, dont le seul but était de déposer un RAT multiplateforme (Windows, macOS, Linux) via un script postinstall, transformant chaque npm install en vecteur d’infection potentielle.

Avec plus de ~100 M de téléchargements hebdomadaires, axios se situe parmi les packages npm les plus utilisés, ce qui fait de cet incident l’une des compromissions supply chain les plus graves jamais observées dans l’écosystème JavaScript.

L’attaque s’est caractérisée par une préparation minutieuse (staging préalable de la dépendance malveillante), un usage intensif d’anti-forensics (auto-suppression, manipulation de package.json) et un contournement des pipelines CI/CD habituels du projet.

Les équipes CTI Google l'ont récemment attribué à un cluster d'attaquant Nord coréen : https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package.

En effet, les recherches du Google Threat Intelligence Group (GTIG) et d'Elastic Security Labs, cette attaque déploie la porte dérobée WAVESHAPER.V2 et est attribuée au groupe nord-coréen.

Contexte et importance d’axios

Axios est une bibliothèque HTTP largement adoptée dans l’écosystème JavaScript/TypeScript, utilisée aussi bien côté serveur (Node.js) que côté client (navigateurs, frameworks front). Elle sert de couche d’abstraction standard pour les appels API dans d’innombrables applications et services.

Sur npm, axios enregistre plus de 80 à 100 millions de téléchargements hebdomadaires et fait partie du top des dépendances transitives dans d’innombrables chaînes de build CI.

Cette centralité en fait une cible idéale pour les attaquants souhaitant :

Maximiser la surface d’infection avec un effort minimal.
Exploiter la confiance aveugle accordée aux mises à jour « mineures » dans les contraintes de version (ex. ^1.14.0).
Propager du code malveillant de manière silencieuse via des dépendances transitives.

Chronologie de l’incident

Les différentes analyses publiées par des éditeurs de sécurité permettent de reconstituer une chronologie opérationnelle relativement précise.

Étapes clés

30 mars 2026, ~05:57 UTC : publication de plain-crypto-js@4.2.0, une version apparemment légitime, destinée à établir un historique « propre » et à réduire les soupçons des systèmes de détection (reputation seeding).
30 mars 2026, 23:59 UTC : publication de plain-crypto-js@4.2.1 avec introduction d’un script postinstall malveillant (déployant un dropper RAT).
31 mars 2026, 00:21 UTC : le compte npm compromis jasonsaayman publie axios@1.14.1, ajoutant plain-crypto-js comme nouvelle dépendance.
31 mars 2026, 01:00 UTC : publication de axios@0.30.4, même mode opératoire, touchant la branche 0.x encore largement utilisée.
31 mars 2026, vers 03:00–04:00 UTC : détection par des outils de sécurité supply chain et remontée publique de l’incident ; suppression des versions malveillantes d’axios et de plain-crypto-js du registre npm.

La fenêtre d’exposition a été relativement courte (de l’ordre de quelques heures), mais conjuguée au volume d’usage d’axios, elle a suffi à entraîner des exécutions réelles du payload dans des environnements CI/CD et de production.

Vecteur initial : compromission du compte mainteneur

Le pivot initial de l’attaque est la compromission du compte npm jasonsaayman, un des mainteneurs principaux d’axios. Les attaquants ont modifié l’adresse e‑mail associée au compte vers ifstap@proton.me, puis utilisé les identifiants ou le jeton d’accès npm pour publier manuellement les versions trojanisées.

Points notables :

Les versions malveillantes apparaissent dans le registre comme publiées par le mainteneur officiel, ce qui contourne le réflexe de méfiance vis‑à‑vis de nouveaux comptes.
Aucun commit, tag ou release correspondant n’existe dans le dépôt GitHub officiel : les builds ont été poussés en dehors du pipeline GitHub Actions/Trusted Publisher habituel du projet.
La suppression du script "prepare": "husky" dans package.json indique une modification manuelle du fichier, sans repasser par les outils de release standard d’axios.

Ce scénario illustre un risque structurel majeur : la sécurité des comptes de mainteneurs est devenue un maillon critique de la sécurité globale de l’écosystème open source.

Mécanisme de la dépendance malveillante

Ajout discret de plain-crypto-js

Dans les versions compromises (1.14.1 et 0.30.4), le diff fonctionnel principal est l’ajout de plain-crypto-js@^4.2.1 dans la section dependencies de package.json d’axios. Aucun fichier source JavaScript d’axios n’importe cette bibliothèque, ce qui confirme qu’elle ne sert qu’à exécuter son postinstall.

Les comportements observés :

plain-crypto-js contient un script postinstall qui télécharge et exécute un dropper RAT depuis un serveur de commande et contrôle (C2).
L’exécution se déclenche au moment de l’installation (npm install), indépendamment du fait que le code applicatif appelle ou non axios dans son runtime.

Distribution du RAT multiplateforme (WAVESHAPER.V2)

Selon l'analyse approfondie d'Elastic Security Labs, l'aspect le plus remarquable de cette campagne est son outillage de phase 2 (stage-2 implants). Les attaquants ont déployé trois implémentations parallèles du même RAT, ciblant spécifiquement chaque système d'exploitation:

Le script postinstall contacte un serveur C2 (par ex. un domaine ou IP spécifique, parfois sur port 8000) pour récupérer un payload adapté à l’OS de la machine.
Le payload agit comme un remote access trojan : shell inverse, exécution de commandes arbitraires, exfiltration de secrets (variables d’environnement, clés, jetons), et persistance locale selon l’OS.
Des techniques d’obfuscation (Base64, XOR, chaînes morcelées, code empaqueté) rendent le code difficile à analyser et permettent d’échapper à des signatures statiques simples.

Bien qu'ils soient écrits dans des langages différents, ces trois implants partagent un protocole C2 (Command & Control) identique, la même structure de commandes, la même cadence de balisage (beaconing) et des User-Agents usurpés similaires. GTIG a identifié cette porte dérobée comme étant WAVESHAPER.V2.

Une fois actif, le RAT offre un accès shell inversé complet, permet l'exécution de commandes arbitraires et met en place une persistance locale.

Techniques de furtivité et anti-forensics

Plusieurs éléments témoignent d’une attention particulière portée à l’évasion et à la complexité de l’investigation post‑incident.

Principales techniques observées :

Auto‑suppression : après exécution, les artefacts malveillants se suppriment, laissant peu de traces dans node_modules et le système de fichiers.
Réécriture de package.json : le package.json installé de plain-crypto-js est modifié pour indiquer la version 4.2.0 alors que la version distribuée malveillante est 4.2.1, ce qui trompe les vérifications ultérieures (npm list, inventaires).
Absence de modifications du code axios : aucune ligne de code de la librairie principale n’est modifiée, réduisant la probabilité de détection via revue de code ou analyse différentielle.
Fenêtre d’exposition courte : tous les artefacts malveillants ont été retirés relativement vite du registre npm, ce qui réduit le volume de preuves disponibles mais complique aussi le travail de rétro‑analyse.

Ces choix montrent un modèle d’attaque pensé pour limiter la visibilité après coup tout en assurant une capacité d’infection substantielle sur une courte durée.

Impact et surface d’attaque

Projets potentiellement exposés

Toute chaîne de dépendances qui :

Référençait axios avec une contrainte de version permettant de tirer automatiquement 1.14.1 ou 0.30.4 (ex. ^1.14.0, ^0.30.0).
A exécuté npm install, npm ci ou un équivalent (y compris dans des pipelines CI/CD) pendant la fenêtre du 31 mars 2026 entre 00:21 et 03:20 UTC où les versions malveillantes étaient disponibles.

est considérée comme potentiellement compromise.

Compte tenu de la popularité d’axios, les environnements concernés incluent :

Applications web front (React, Vue, Angular, etc.).
Backends Node.js (API REST, BFF, microservices).
Pipelines d’intégration continue, scripts de build et outils CLI internes.

Même si le nombre total d’installations de ces versions précises reste inférieur aux 100 M de téléchargements hebdomadaires d’axios en temps normal, plusieurs acteurs évoquent une exécution mesurable du payload dans la nature.

Données et actifs à risque

Les rapports confirment que le RAT a été conçu pour récolter massivement des données à haute valeur ajoutée.

Les attaquants ciblaient spécifiquement :

Les identifiants et fichiers de configuration Cloud (AWS, Azure, GCP).
Les tokens Kubernetes.
Les clés SSH et les portefeuilles de cryptomonnaies (crypto wallets).
Les secrets stockés dans les variables d’environnement (fichiers .env, clés API, tokens CI).

L’obtention de ces secrets ouvre la voie à un mouvement latéral dévastateur depuis les runners CI/CD vers l'infrastructure de production cloud des victimes.

Détection et investigation

Indicateurs de compromission (IoC) – exemples

Les publications des éditeurs de sécurité et de recherche listent plusieurs IoC notables autour de cette campagne :

Présence (historique) des versions axios@1.14.1 ou axios@0.30.4 dans les lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock) ou les journaux de build.
Références à plain-crypto-js@4.2.1 dans ces mêmes fichiers ou dans des logs d’installation npm.
Requêtes sortantes de machines de build ou de postes développeurs vers les domaines/IP C2 identifiés, sur des ports non usuels (par ex. 8000).
Traces d’exécution de scripts postinstall non attendus dans les logs npm, Yarn ou pnpm.
Éventuels binaires ou scripts laissés sur disque avant auto‑suppression si la machine a pu être figée (snapshots, sauvegardes) peu après l’incident.

Approche d’analyse recommandée

Pour les organisations potentiellement exposées, la réponse doit inclure :

L’analyse de l’historique des builds CI/CD et des installs npm sur la période concernée (jobs, artefacts, logs).
La recherche de axios@1.14.1, axios@0.30.4 et plain-crypto-js@4.2.1 dans l’ensemble des dépôts, lockfiles et caches de dépendances.
La corrélation avec les logs réseau/Proxy/Firewall pour détecter d’éventuelles communications C2.
Un examen des endpoints compromis pour repérer toute persistance ou trace d’activité post‑compromission.

Mesures de remédiation

Pour les projets potentiellement touchés

Les recommandations convergentes des différents acteurs sécurité incluent :

Isoler et auditer : Isoler les hôtes potentiellement affectés et auditer l'historique des builds CI/CD sur la période d'exposition.
Rotation des secrets (Critique) : Considérer tous les secrets accessibles (Cloud, Kubernetes, SSH, API) par les environnements touchés comme compromis et les renouveler immédiatement.
Purger et réinstaller : Supprimer les node_modules, nettoyer les caches npm/pnpm/yarn, puis rétrograder vers des versions sûres (npm install axios@1.14.0 ou 0.30.3).

Durcissement à moyen terme

Au‑delà de la remédiation immédiate, l’incident axios met en lumière plusieurs chantiers structurels :

Renforcement de la sécurité des comptes mainteneurs : MFA obligatoire, tokens d’accès à durée de vie courte, revue périodique des accès, détection d’anomalies de connexion.
Généralisation des Trusted Publishers / OIDC : n’autoriser la publication de packages npm que depuis des pipelines CI signés et vérifiés, avec métadonnées exploitables par les outils de sécurité.
Politiques de pinning et de signature : utilisation de lockfiles stricts, de hashes de packages (intégrité Subresource Integrity, npm integrity), voire de registres privés mirroirs contrôlés.
Surveillance des hooks de cycle de vie npm : audits automatiques des scripts preinstall, postinstall, etc., et blocage par défaut dans certains environnements sensibles (CI, prod).
Outils de sécurité supply chain : intégration d’outils capables de détecter ajouts de dépendances anormales, modifications de provenance de publication, et comportements réseau suspects lors des builds.

Impliquez des équipes de réponse à incident si vous suspectez être compromis : https://www.safercy.com/reponse-a-incident.

Conclusion

L’attaque contre axios s’inscrit dans une tendance plus large de compromissions supply chain ciblant l’écosystème npm, aux côtés de campagnes comme Shai Hulud/sha1-hulud ou d’attaques de typosquatting sur des packages mimant axios (axois, etc.). Elle confirme que :

La confiance implicite dans les mainteneurs et les mises à jour « mineures » n’est plus tenable à grande échelle.
Les hooks d’installation npm et les dépendances transitives sont devenus un vecteur privilégié pour les RAT, voleurs de secrets et autres malwares avancés.
Les organisations doivent traiter leur chaîne de build et de dépendances comme une surface d’attaque critique, au même titre que leurs services exposés sur Internet.

Pour l’écosystème open source, cette affaire renforce l’urgence de :

Outiller et accompagner les mainteneurs (sécurité des comptes, automatisation des releases, sponsoring de solutions de sécurité).
Mettre en place des garanties techniques permettant aux consommateurs de packages de vérifier l’origine, l’intégrité et la provenance des artefacts installés - le fait d'activer le pinning de version notamment.
Éduquer développeurs et équipes DevOps sur les signaux faibles d’une compromission supply chain et les bonnes pratiques de réponse.

En résumé, la compromission d’axios illustre un scénario où un seul compte mainteneur compromis suffit à transformer un package massivement utilisé en cheval de Troie global. Elle impose une réévaluation profonde des modèles de confiance actuels dans les registres publics de packages et dans les chaînes de compilation modernes.