- Un attaquant a compromis le compte npm du principal responsable d'Axios et a publié les versions 1.14.1 et 0.30.4 avec une dépendance fantôme, plain-crypto-js, qui a déployé un RAT multiplateforme lors de l'installation.
- Le logiciel malveillant a contacté un serveur C2 (sfrclak[.]com) et a téléchargé des charges utiles spécifiques pour Windows, macOS et Linux, effectuant une reconnaissance du système, maintenant des balises périodiques et, dans certains cas, établissant une persistance.
- L'attaque, attribuée par Google et d'autres chercheurs à l'acteur nord-coréen UNC1069, a combiné une fenêtre d'exposition d'environ trois heures avec une campagne d'ingénierie sociale sophistiquée contre le responsable du système afin de voler ses identifiants.
- Les organisations qui ont pu installer les versions concernées doivent s'engager à prendre des mesures, à rechercher les artefacts RAT, à renouveler les identifiants, à utiliser des versions sécurisées d'Axios et à renforcer leurs contrôles de chaîne d'approvisionnement, d'intégration continue/déploiement continu et de gestion des dépendances.
La communauté des développeurs JavaScript vient de connaître une alerte majeure qui remet en question la confiance accordée à ses dépendances, comme l'ont démontré les problèmes de vulnérabilité des bibliothèques . Axios, l'une des bibliothèques HTTP les plus utilisées de l'écosystème, a été manipulée sur npm pour diffuser un cheval de Troie d'accès à distance (RAT) via des versions apparemment légitimes. L'incident n'a duré que quelques heures, mais il a mis en évidence la fragilité de la chaîne d'approvisionnement logicielle, bien plus importante qu'on ne le pensait.
Le problème majeur ne réside pas seulement dans le fait que les attaquants aient réussi à introduire un logiciel malveillant dans un paquet téléchargé des dizaines, voire des centaines de millions de fois par semaine. Le véritable problème est qu'ils ont procédé en piratant le compte npm du principal mainteneur, en publiant des versions « officielles » d'apparence normale, sans modifier une seule ligne du code source d'Axios . Toute la malveillance était dissimulée dans une dépendance fantôme conçue spécifiquement pour l'attaque.
Comment l'engagement d'Axios envers npm a vu le jour
Pour comprendre l'ampleur de l'incident, il faut remonter au point d'entrée. L'attaquant a réussi à prendre le contrôle du compte npm de « jasonsaayman », le principal mainteneur d'Axios, et a modifié l'adresse électronique associée pour une adresse sous son contrôle , hébergée sur Proton Mail. Dès lors, il a pu publier librement de nouvelles versions du paquet en se faisant passer pour le mainteneur.
À l'aide de ces identifiants, il a téléchargé deux versions malveillantes d'Axios : 1.14.1 et 0.30.4 , couvrant les deux branches principales du projet. Les téléchargements ont été effectués à seulement 39 minutes d'intervalle et, selon l'analyse de StepSecurity, directement depuis npm à l'aide d'un jeton à longue durée de vie classique, contournant ainsi le pipeline CI/CD habituel basé sur GitHub Actions.
Dix-huit heures avant l'attaque finale, l'auteur avait déjà publié une version « propre » de la dépendance malveillante sur le registre npm . Cette étape préliminaire a permis de constituer un historique et d'empêcher le déclenchement de certains contrôles automatisés lors de l'apparition d'un paquet entièrement nouveau au moment de l'attaque.
Ce qui est frappant, c'est que les attaquants n'ont pas modifié le code source d'Axios ni apporté de changements visibles au dépôt GitHub . En effet, les versions 1.14.1 et 0.30.4 n'avaient aucun commit ni tag correspondant sur GitHub ; elles existaient uniquement sur npm. La principale différence résidait dans le fichier de dépendances du paquet, qui était publié dans le registre.
En temps normal, Axios ne déclare que trois dépendances : follow-redirects, form-data et proxy-from-env . Cependant, dans les versions compromises, une quatrième dépendance est apparue, auparavant inexistante dans le projet : plain-crypto-js, version 4.2.1. Cette bibliothèque fantôme n’était utilisée nulle part dans le code source d’Axios, mais elle incluait un script de post-installation qui s’exécutait automatiquement lors de l’installation du paquet avec npm, pnpm ou des outils similaires.
plain-crypto-js : la dépendance fantôme déployée par le RAT
La clé de l'attaque résidait dans cette dépendance supplémentaire. Le paquet plain-crypto-js a été publié sur npm par un utilisateur nommé « nrwise », également associé à une adresse e-mail Proton Mail, et son unique but était d'exécuter un script de post-installation obfusqué en Node.js (setup.js) . Ce script servait de dropper, c'est-à-dire d'installateur initial pour la seconde phase du logiciel malveillant.
Lors de l'installation d'Axios dans une version compromise, le cycle de vie post-installation de npm a automatiquement déclenché le code plain-crypto-js sans intervention du développeur . Le programme d'installation s'est connecté à un serveur de commande et de contrôle (C2) actif dans le domaine sfrclakcom, écoutant sur le port 8000, et a téléchargé une charge utile spécifique au système d'exploitation de la machine infectée ; ce comportement est détectable par l'analyse du trafic réseau.
Les chercheurs de StepSecurity et d'autres équipes d'analyse décrivent un comportement extrêmement prudent. Après l'exécution du code malveillant, le programme d'installation a effacé ses traces : il a supprimé le script postinstall, remplacé le fichier package.json par une version « propre » et laissé un fichier node_modules qui, à première vue, semblait inoffensif . De cette manière, une inspection manuelle ultérieure n'a pas permis de détecter directement le code malveillant dans Axios.
Pour identifier la manipulation, le seul indice fiable résidait dans les fichiers de verrouillage (package-lock.json, pnpm-lock.yaml, yarn.lock) et la présence de versions spécifiques : axios 1.14.1 ou 0.30.4 et plain-crypto-js 4.2.1, ainsi que deux versions intermédiaires de ce paquet (4.2.0 et 4.2.2) identifiées dans certaines analyses. Socket a par la suite détecté que le même logiciel malveillant était également distribué via les paquets @shadanai/openclaw (diverses versions 2026.3.xx) et @qqbrowser/openclaw-qbot (0.0.130). Des techniques de sécurité telles que les honeypots peuvent également contribuer à identifier des campagnes similaires.
RAT multiplateforme : Windows, macOS et Linux sous les projecteurs
Une fois exécuté, le script setup.js agissait comme un orchestrateur capable de détecter le système d'exploitation et de suivre un parcours d'attaque spécifique à chaque plateforme . La campagne était manifestement préparée à l'avance : selon StepSecurity, les attaquants disposaient de trois charges utiles distinctes précompilées, une pour chaque système.
Sur les systèmes macOS, le processus post-installation lançait un script AppleScript qui téléchargeait un fichier binaire infecté par un cheval de Troie depuis le serveur sfrclakcom:8000 . Ce fichier était enregistré dans le répertoire /Library/Caches/com.apple.act.mond, ses permissions étaient modifiées pour le rendre exécutable, puis il était lancé en arrière-plan via /bin/zsh. Une fois le RAT en fonctionnement, le script AppleScript était supprimé afin de compliquer l'analyse forensique.
Sur les machines Windows, le logiciel malveillant localisait le fichier binaire PowerShell du système, le copiait dans %PROGRAMDATA%\wt.exe pour le faire passer pour le terminal Windows, et générait un script VBS temporaire . Ce script VBS contactait ensuite le serveur de commande et de contrôle (C2) pour télécharger un script PowerShell supplémentaire destiné à un RAT (Remote Access Trojan), l'exécutait, puis supprimait le fichier téléchargé. De plus, la variante Windows créait le fichier %PROGRAMDATA%\system.bat contenant une routine de téléchargement permettant au logiciel malveillant de se réinstaller à chaque connexion et ajoutait une clé d'exécution au registre Windows pour assurer sa persistance.
Sur Linux et autres systèmes de type Unix, à l'exception de macOS, le programme d'installation utilisait la fonction `execSync` de Node.js pour lancer une commande shell qui téléchargeait un script Python depuis `sfrclakcom`, l'enregistrait sous `/tmp/ld.py` et l'exécutait avec `nohup` pour le maintenir actif en arrière-plan . Contrairement à Windows, cette variante ne présentait pas de mécanisme de persistance robuste, ce qui suggère une approche plus rapide, axée sur l'exfiltration de données, ou le déploiement ponctuel d'une persistance via des commandes ultérieures.
SafeDep et Elastic Security Labs ont analysé les charges utiles de second niveau et ont conclu que les RAT pour macOS (binaire Mach-O en C++) et Linux (script Python) partageaient le même ensemble de commandes, le même protocole C2, le même format de message et le même comportement opérationnel . Ce type d'analyse s'appuie généralement sur des services d'analyse comme VirusTotal , qui facilitent la corrélation des échantillons et des indicateurs de compromission (IOC).
Dans tous les cas, chaque hôte compromis effectuait une reconnaissance système immédiate : répertoires utilisateurs, racines des disques, processus actifs et autres métadonnées . Ces informations étaient envoyées au serveur de commande et de contrôle, et l’agent maintenait une boucle de surveillance d’environ 60 secondes, en attente de nouvelles instructions, notamment l’exécution de scripts supplémentaires ou l’injection de fichiers binaires en mémoire.
Fenêtre d'exposition, objectifs et attribution à la Corée du Nord
Les versions malveillantes d'Axios étaient disponibles sur npm pendant environ trois heures, au cours d'une période soigneusement choisie. Les paquets compromis ont été publiés juste avant minuit dimanche (un moment qui a permis aux équipes de sécurité de réagir au mieux), et l'incident a été maîtrisé tôt lundi matin , après que des entreprises de sécurité ont alerté les autorités de ce comportement anormal.
Durant cette période relativement courte, Huntress a détecté au moins 135 systèmes se connectant au serveur de l'attaquant . Sachant qu'Axios enregistre entre 80 et 100 millions de téléchargements par semaine (voire plus de 300 millions selon certaines sources), ce chiffre ne représente probablement que la partie émergée de l'iceberg, se limitant aux systèmes repérés par les sociétés d'analyse ayant rendu leurs données publiques.
Google, par l'intermédiaire de son équipe de veille sur les menaces, a attribué l'attaque à un acteur nord-coréen présumé, identifié sous le nom d'UNC1069 . Elastic Security Labs a renforcé cette hypothèse en constatant une forte similitude entre le RAT déployé sur macOS et WAVESHAPER, une porte dérobée C++ découverte par Mandiant et également liée au même groupe de menaces.
Les analystes de Google ont souligné que des groupes liés à la Corée du Nord se spécialisent depuis des années dans les attaques contre la chaîne d'approvisionnement et le vol de cryptomonnaies . Le mode opératoire est constant : compromettre l'infrastructure de développement, les bibliothèques largement utilisées ou les logiciels de confiance afin de s'attaquer ensuite à des cibles gérant des actifs de grande valeur, des clés privées ou des identifiants.
Plusieurs rapports ont également souligné que la conception et la modération de l'attaque suggéraient l'intervention d'une équipe bien coordonnée : trois implémentations parallèles du même RAT (PowerShell, C++ et Python), un protocole C2 cohérent, un comportement quasi identique pour toutes les variantes et une stratégie d'auto-nettoyage claire afin d'éviter toute trace. Elastic a insisté sur le fait que cette cohérence indique plutôt l'implication d'un seul développeur ou d'un groupe travaillant à partir d'un document de conception partagé, et non une improvisation.
Au-delà des aspects purement techniques, l'un des points les plus troublants de cette affaire réside dans le piratage du compte npm du principal responsable de la maintenance. Ce dernier a expliqué par la suite avoir activé l'authentification à deux facteurs sur la quasi-totalité de ses services , et avoir malgré tout accordé l'accès sans s'en rendre compte.
D'après l'analyse post-mortem réalisée par l'équipe, les attaquants ont mis en place une opération d'ingénierie sociale très élaborée, s'appuyant sur des outils d'intelligence artificielle, afin de gagner la confiance de leurs victimes . Ils se sont fait passer pour le fondateur de l'entreprise, copiant son identité visuelle, sa photo et même son logo. Ils ont créé un véritable espace Slack avec le logo de l'entreprise, des chaînes dont les publications étaient censées être synchronisées avec LinkedIn, et même de faux profils d'employés et d'autres contributeurs de logiciels libres.
Dans ce contexte, ils ont programmé une réunion via Microsoft Teams à laquelle participait un groupe complet de professionnels . Au cours de cette réunion, ils ont simulé un problème technique et indiqué qu'un composant de leur système était obsolète. Le technicien de maintenance, croyant qu'il s'agissait d'une exigence légitime liée à l'outil de visioconférence, a téléchargé et installé le fichier suggéré.
Ce fichier était en réalité le cheval de Troie d'accès à distance qui a permis aux attaquants d'obtenir les identifiants de la victime et, finalement, de prendre le contrôle du compte npm utilisé pour publier Axios . L'ensemble du processus était si bien orchestré, avec tant de détails crédibles, que la victime l'a décrit comme « parfaitement coordonné, professionnel et totalement convaincant ».
Cet élément humain dans l'incident démontre clairement que même des mesures techniques comme l'authentification à deux facteurs sont insuffisantes lorsque l'ingénierie sociale de haut niveau se combine à l'usurpation d'identité visuelle, aux deepfakes ou au clonage détaillé d'organisations . Le maillon faible, une fois de plus, reste l'interaction humaine.
Impact sur les organisations et les développeurs utilisant Axios
D'un point de vue pratique, le principal problème consiste à déterminer qui a été réellement touché. Toute organisation ayant installé [email protected] ou [email protected] pendant la période où ils étaient disponibles doit considérer que la machine ou le système ayant effectué l'installation peut être compromis.
Les recommandations d'entreprises comme StepSecurity, Aikido, Huntress et Elastic sont sans équivoque : en cas de suspicion, une approche proactive est indispensable, et non la simple suppression et réinstallation des modules Node.js. La démarche prudente consiste à reconstruire les machines ou environnements concernés à partir d'images fiables et à examiner attentivement les journaux CI/CD afin d'identifier les tâches ou pipelines ayant pu exécuter les versions compromises.
De plus, il est crucial de renouveler tous les identifiants et secrets auxquels le RAT aurait pu accéder depuis ces nœuds : jetons npm, clés de fournisseur cloud, secrets de pipeline, identifiants de base de données, clés SSH, etc. Laisser ces identifiants en circulation après une telle attaque ouvre la porte à des déplacements latéraux silencieux.
Sur le plan technique, les équipes doivent examiner leurs fichiers de verrouillage (package-lock.json, pnpm-lock.yaml, yarn.lock) afin d'y rechercher des références aux versions compromises d'Axios et de plain-crypto-js . Si de tels éléments sont détectés, l'étape suivante consiste à inspecter les systèmes affectés à la recherche d'éventuels artefacts de type RAT : /Library/Caches/com.apple.act.mond sous macOS, %PROGRAMDATA%\wt.exe et %PROGRAMDATA%\system.bat sous Windows, ou /tmp/ld.py sous Linux.
Parallèlement, il est recommandé de définir explicitement des versions sécurisées d'Axios, telles que 1.14.0 et 0.30.3, et d'utiliser des substitutions ou des résolutions pour empêcher les dépendances transitives de se résoudre vers des versions indésirables . Bloquer le trafic sortant vers le domaine sfrclakcom constitue également une mesure de confinement judicieuse, au moins le temps d'analyser l'étendue complète de l'attaque.
Leçons de sécurité pour la chaîne d'approvisionnement logicielle
L'incident Axios n'est pas un cas isolé, mais un maillon de plus dans une chaîne d'attaques ciblant la chaîne d'approvisionnement, qui comprend des affaires comme SolarWinds, Kaseya, 3CX, Polyfill.io et les vulnérabilités exploitées dans Log4j. Le principe reste le même : compromettre un composant largement utilisé et fiable pour maximiser la portée des attaques , plutôt que de tenter d'attaquer chaque machine individuellement.
L'une des leçons les plus fréquemment répétées par les experts est que la confiance ne peut reposer uniquement sur la popularité d'une bibliothèque ou la réputation de son responsable . Si le canal de distribution (le compte npm, le pipeline CI/CD, l'infrastructure de compilation) est compromis, tout ce qui est distribué par ce biais hérite de ce risque. La revue de code manuelle est également insuffisante si un logiciel malveillant se dissimule dans des dépendances transitives et s'autodétruit après son exécution.
Il a également été souligné que la vitesse par défaut des mises à jour de dépendances a un coût en termes de surface d'attaque . Adopter systématiquement et automatiquement la dernière version est certes très pratique, mais cela permet à une mise à jour malveillante de se propager en quelques minutes. Certaines organisations envisagent déjà des politiques telles que l'exigence qu'une nouvelle version soit présente dans l'écosystème depuis un certain temps avant son adoption, ou l'obligation pour les modifications apportées aux paquets critiques de faire l'objet d'un examen manuel supplémentaire.
Concernant l'infrastructure de développement, les environnements CI/CD doivent être considérés comme des actifs hautement sensibles . Tout RAT exécuté lors de l'installation des dépendances cherchera presque certainement à obtenir les secrets du pipeline et à accéder à d'autres environnements. Segmenter ces nœuds, les surveiller de plus près et renouveler régulièrement leurs secrets n'est plus une simple recommandation, mais une nécessité.
Enfin, la détection de ce type d'attaques nécessite la combinaison d'informations provenant de sources multiples : versions installées, fichiers de verrouillage, indicateurs de compromission du système d'exploitation et données de télémétrie réseau . Les outils de génération et de gestion des nomenclatures logicielles (SBOM) permettent d'identifier rapidement les projets utilisant quels paquets, ce qui est crucial lors du déclenchement d'alertes massives comme celle-ci.
Cet épisode avec Axios illustre à quel point l'écosystème des dépendances, aussi mature et consolidé soit-il en apparence, repose encore largement sur la confiance et une vigilance constante. Une bibliothèque apparemment inoffensive, maintenue par une seule personne victime d'une attaque d'ingénierie sociale bien menée, peut devenir, en quelques heures, un vecteur mondial de déploiement de RAT (Remote Access Trojan) multiplateformes ciblant entreprises, indépendants et organisations de toutes tailles . Renforcer les contrôles autour des comptes de publication, des pipelines et des dépendances critiques n'est plus une simple option, mais une condition sine qua non pour assurer la continuité du développement dans un environnement où les attaquants sont de plus en plus patients, ingénieux et équipés d'outils plus performants.
