Paquet npm Axios compromis : une attaque de la chaîne d’approvisionnement déploie un RAT multiplateforme

Le 31 mars 2026, deux versions malveillantes d’axios, le client HTTP JavaScript extrêmement populaire, téléchargé plus de 100 millions de fois par semaine, ont été brièvement publiées sur npm depuis le compte compromis d’un mainteneur. Ces paquets contenaient une dépendance cachée qui déployait un cheval de Troie d’accès à distance multiplateforme (RAT) sur toute machine ayant exécuté npm install (ou l’équivalent dans d’autres gestionnaires de paquets comme Bun) pendant une fenêtre de deux heures.

Les versions malveillantes (1.14.1 et 0.30.4) ont été retirées de npm à 03:29 UTC. Mais pendant leur mise à disposition, toute personne dont le pipeline CI/CD, l’environnement de développement ou le système de build a effectué une nouvelle installation a pu être compromise sans même toucher à une ligne de code Axios.

En bref

Comment l’attaque a été montée

Il ne s’agit pas d’un paquet typosquatté ni d’une dépendance malveillante qui se serait glissée dans un build. L’attaquant disposait (ou a obtenu) d’un accès direct à la publication du paquet officiel axios sur npm, probablement en compromettant le compte d’un mainteneur. Selon un collaborateur dans le fil officiel du problème GitHub, le compte probablement compromis appartenait au mainteneur @jasonsaayman, dont les autorisations sur le dépôt étaient supérieures à celles des autres collaborateurs, ce qui a compliqué une remédiation rapide.

L’attaquant n’a modifié directement aucun fichier source d’Axios. À la place, il a ajouté une dépendance malveillante préparée à l’avance, plain-crypto-js@4.2.1, au fichier package.json des nouvelles versions d’axios. Le paquet plain-crypto-js avait été spécialement conçu pour cette attaque : une version antérieure « propre » (4.2.0) avait été publiée 18 heures auparavant, probablement pour lui donner un bref historique sur le registre. La version 4.2.1 contenait la charge utile malveillante.

Lorsqu’un développeur ou un système CI exécute npm install axios@1.14.1, npm résout l’arborescence des dépendances, récupère plain-crypto-js@4.2.1 et exécute automatiquement son script postinstall : node setup.js. C’est l’exécution de ce script qui déclenche la compromission.

Le programme de dépôt : doublement obfusqué et auto-effaceur

Le dropper setup.js exécuté lors de l’installation utilise deux couches d’obfuscation pour échapper à l’analyse statique :

1. Encodage Base64 inversé avec substitution du caractère de remplissage

2. Chiffrement XOR avec la clé OrDeR_7077 et une valeur constante de 333

Une fois désobfusqué, le script détecte le système d’exploitation de l’hôte à l’aide de os.platform() et contacte le serveur C2 à l’adresse sfrclak[.]com:8000 (IP : 142.11.206.73) pour télécharger une charge utile de deuxième étape adaptée à la plateforme.

Après son exécution, le logiciel malveillant efface ses traces : il supprime setup.js, supprime le package.json qui contenait le script postinstall et le remplace par un package.md propre renommé en package.json. Si vous inspectez node_modules/plain-crypto-js après coup, vous ne trouverez aucun signe évident de la présence d’un script postinstall.

Charges utiles propres à chaque plateforme

Les charges utiles de deuxième étape sont conçues spécifiquement pour chaque plateforme.

macOS

Un AppleScript télécharge un binaire dans /Library/Caches/com.apple.act.mond, en usurpant délibérément une convention de nommage des démons d’arrière-plan Apple pour se fondre dans le système. Une fois installé, le RAT :

• Génère un identifiant de victime unique de 16 caractères

• Collecte l’empreinte du système : nom d’hôte, nom d’utilisateur, version de macOS, heures de démarrage/d’installation, architecture du processeur (mac_arm ou mac_x64), processus en cours

• Envoie un signal au C2 toutes les 60 secondes avec une fausse chaîne User-Agent d’IE8/Windows XP

• Accepte quatre commandes de l’attaquant :

  • peinject : reçoit un binaire encodé en Base64 depuis le C2, le décode, l’écrit dans un fichier temporaire caché (par exemple /private/tmp/.XXXXXX), signe le code de manière ad hoc via codesign --force --deep --sign - pour contourner Gatekeeper, puis l’exécute

  • runscript : exécute des commandes shell arbitraires via /bin/sh ou exécute des fichiers AppleScript via osascript

  • rundir : énumère les métadonnées du système de fichiers de /Applications, ~/Library et ~/Application Support

  • kill : met fin au processus du RAT

Windows

Un téléchargeur VBScript copie le binaire PowerShell dans %PROGRAMDATA%\wt.exe (en se faisant passer pour Windows Terminal) et exécute un RAT PowerShell caché avec des indicateurs qui contournent la stratégie d’exécution.

Linux

Un RAT Python est téléchargé dans /tmp/ld.py et lancé en processus d’arrière-plan orphelin via nohup python3, ce qui le détache de la session de terminal qui l’a démarré.

Autres paquets compromis

Deux autres paquets ont été observés avec la dépendance malveillante plain-crypto-js :

• @qqbrowser/openclaw-qbot@0.0.130 — inclut un axios@1.14.1 altéré, avec la dépendance injectée (SNYK-JS-QQBROWSEROPENCLAWQBOT-15850776)

• @shadanai/openclaw (versions 2026.3.31-1, 2026.3.31-2) — intègre directement plain-crypto-js (SNYK-JS-SHADANAIOPENCLAW-15850775)

Ces paquets secondaires laissent penser soit à une infrastructure d’attaque coordonnée, soit à une utilisation active de plain-crypto-js dans des campagnes connexes.

Qui est réellement exposé ?

La fenêtre de publication de trois heures (00:21 à 03:29 UTC) est le facteur déterminant. Le risque est le plus élevé pour :

• Les pipelines CI/CD qui ne verrouillent pas les versions des dépendances et exécutent npm install de façon planifiée ou à chaque commit, en particulier ceux qui fonctionnent pendant la nuit ou tôt le matin en UTC.

• Les développeurs qui ont exécuté npm install ou npm update pendant cette fenêtre et ont récupéré les versions concernées.

• Les projets dépendant de @qqbrowser/openclaw-qbot ou @shadanai/openclaw, dont l’exposition ne dépend pas de la fenêtre.

Si votre fichier de verrouillage (package-lock.json ou yarn.lock) a été validé avant la publication des versions malveillantes et que votre installation ne l’a pas mis à jour, vous n’avez pas été affecté. Les fichiers de verrouillage sont votre première ligne de défense dans ce cas.

Les versions malveillantes ont été retirées du registre npm. Toutefois, toute personne qui les a installées pendant la fenêtre doit considérer son système comme entièrement compromis : le RAT était actif, communiquait avec son serveur et pouvait exécuter des charges utiles ultérieures arbitraires.

Remédiation avec Snyk et vérification de votre exposition

Si vous utilisez Snyk ou en êtes client, l’une des différentes intégrations Snyk vous signalera tout projet intégrant la version compromise et malveillante de la dépendance axios, que ce soit via la CLI Snyk, l’intégration de l’application Snyk ou tout autre moyen.

La base de données de Snyk comprend des entrées pour SNYK-JS-AXIOS-15850650 et SNYK-JS-PLAINCRYPTOJS-15850652. Ainsi, snyk test signalera les versions concernées et la dépendance transitive malveillante.

De plus, si vous avez souscrit au forfait Enterprise, vous verrez un rapport Zero Day dans l’application, comme pour des incidents de sécurité zero-day antérieurs tels que LiteLLM, Shai-Hulud et d’autres. Ce rapport vous donne une vue d’ensemble du système pour localiser et identifier facilement les projets et dépôts concernés qui utilisent la dépendance axios vulnérable :

Si vous n’utilisez pas encore Snyk, une offre gratuite est disponible. Vous pouvez commencer facilement et vérifier votre environnement afin de détecter une éventuelle compromission d’axios ou d’autres problèmes de sécurité, comme suit :

# Install Snyk CLI if you haven't already
npm install -g snyk

# Authenticate
snyk auth

# Test your project
snyk test

Pour les utilisateurs de Bun : solution de contournement avec Snyk (la prise en charge native de bun.lock est limitée dans la CLI Snyk au moment de la rédaction de cet article) :

La solution de contournement recommandée consiste à générer un fichier de verrouillage compatible avec yarn.lock à l’aide de l’option intégrée -y de Bun, que Snyk peut analyser :

# 1. Regenerate lockfile in yarn.lock format
bun install -y

# 2. Run snyk against the generated yarn.lock
snyk test --file=yarn.lock

Sinon, vous pouvez suivre les étapes ci-dessous pour déterminer si vous avez été affecté par la compromission d’axios :

Étape 1 : vérifiez les versions concernées dans votre fichier de verrouillage

# Check for axios 1.14.1 or 0.30.4
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# Or with yarn
grep -E 'axios@' yarn.lock | grep -E '1\.14\.1|0\.30\.4'

Étape 2 : recherchez la dépendance malveillante

# Look for plain-crypto-js in your dependency tree
npm ls plain-crypto-js

# Or search node_modules directly
find node_modules -name "plain-crypto-js" -type d

Étape 3 : recherchez les installations de la dépendance axios malveillante avec l’environnement d’exécution Bun

Si vous utilisez Bun, vérifiez votre bun.lock (fichier de verrouillage texte, Bun v1.1+) :

grep -E 'axios' bun.lock | grep -E '1\.14\.1|0\.30\.4'

Vérifiez également la présence de la dépendance transitive malveillante :

grep 'plain-crypto-js' bun.lock

Remarque : les anciennes versions de Bun génèrent un fichier binaire bun.lockb. Pour l’inspecter, convertissez-le d’abord :

> bun bun.lockb  # prints human-readable output to stdout
> bun bun.lockb | grep -E 'axios.*1\.14\.1|axios.*0\.30\.4'
> bun bun.lockb | grep 'plain-crypto-js'

Étape 4 : recherchez les indicateurs de compromission (IOC) sur les systèmes compromis

Si vous pensez qu’une machine a exécuté npm install pendant la fenêtre concernée, recherchez les indicateurs suivants :

Conseils de remédiation supplémentaires pour le gestionnaire de paquets npm

Si vous n’êtes pas concerné (par précaution) :

1. Verrouillez axios sur une version dont la sûreté est connue dans votre package.json. Toutes les versions sauf 1.14.1 ou 0.30.4 sont saines.

2. Validez votre fichier de verrouillage et assurez-vous que CI utilise npm ci (et non npm install) pour garantir l’intégrité de ce fichier.

3. Ajoutez plain-crypto-js à une liste de blocage dans votre gestionnaire de paquets ou vos outils de sécurité.

Envisagez d’activer --ignore-scripts pour les installations npm dans les environnements CI où les hooks de cycle de vie ne sont pas nécessaires :

npm ci --ignore-scripts

Cela empêche complètement l’exécution des scripts postinstall, ce qui aurait bloqué ce vecteur d’attaque. Attention : cette option peut perturber les paquets qui nécessitent légitimement des étapes post-installation (les modules natifs, par exemple).

Envisagez également d’utiliser le projet open source npq et de le déployer auprès de vos développeurs. Il effectue des vérifications préalables de sécurité et de fiabilité avant l’installation des dépendances.

Enfin, nous vous recommandons de consulter ces bonnes pratiques de sécurité npm élaborées par la communauté.

Si vous êtes concerné (considérez le système comme compromis) :

1. Confinez immédiatement : isolez tous les systèmes ayant exécuté npm install pendant la fenêtre concernée.

2. Faites tourner tous vos secrets : considérez chaque identifiant sur la machine concernée comme compromis : clés API, clés SSH, identifiants cloud, jetons npm, jetons GitHub. Ne les faites pas tourner sur place : révoquez-les et réémettez-les.

3. Recherchez tout mouvement latéral : vérifiez les journaux pour repérer les connexions sortantes vers sfrclak[.]com ou 142.11.206.73. Si le RAT était actif, l’attaquant pouvait exécuter du code arbitraire et a pu effectuer des recherches ou exfiltrer davantage de données.

4. Reconstruisez les environnements : ne tentez pas de nettoyer les systèmes compromis. Reconstruisez-les à partir d’un instantané ou d’une image de base dont la propreté est garantie.

5. Auditez les pipelines CI : examinez les journaux de build pour la fenêtre du 31 mars 2026 (UTC) afin de déterminer quels pipelines ont installé les versions concernées.

Vue d’ensemble : sécurité des comptes de mainteneurs

Cette attaque suit un schéma désormais bien connu : compromettre le compte d’un mainteneur légitime, publier une version malveillante d’un paquet de confiance et tirer parti de la confiance implicite de l’écosystème envers les paquets enregistrés. Nous avons déjà vu cette méthode utilisée contre le plugin Prettier d’ESLint, contre plusieurs paquets appartenant à un développeur prolifique, à la suite d’une attaque par hameçonnage, ainsi que dans la campagne Shai-Hulud, qui a compromis plus de 600 paquets.

Ce qui rend l’incident lié à Axios particulièrement préoccupant, c’est son ampleur : avec 100 millions de téléchargements par semaine, même une fenêtre malveillante de deux heures peut avoir des conséquences considérables. L’attaquant a également fait preuve d’une réelle sophistication opérationnelle : préinstallation de la dépendance malveillante, historique de versions « propre », double obfuscation du dropper, création de RAT spécifiques à chaque plateforme et suppression automatique pour effacer les traces. Il ne s’agissait pas d’une attaque opportuniste.

Pour les organisations qui dépendent de l’open source à grande échelle, la leçon n’est pas d’arrêter d’utiliser npm ni de se méfier de toutes les dépendances. Il s’agit de comprendre quelles mesures de contrôle de la chaîne d’approvisionnement auraient permis de détecter cette attaque : imposer l’utilisation des fichiers de verrouillage, auditer les scripts postinstall et surveiller l’exécution de processus inattendus ou les connexions réseau sortantes depuis les environnements de compilation. Le guide de Snyk pour prévenir les attaques de la chaîne d’approvisionnement npm et les considérations de sécurité relatives aux fichiers de verrouillage méritent d’être relus à la lumière de cet incident.

Pour comprendre cette catégorie d’attaques dans son ensemble, Snyk Learn propose une leçon consacrée à la compromission de packages légitimes, qui présente les modes opératoires et les mesures de défense.

Chronologie