Axios compromis : le genre d’attaque qui passe sous ton radar

J’ai installé axios… sans savoir que j’exécutais un malware

C’est exactement le problème.

Tu penses faire un banal :

npm install

Et en réalité, tu lances un script malveillant sur ta machine. Sans alerte. Sans warning. Rien.

C’est ce qui s’est passé avec Axios fin mars 2026. Une attaque supply chain pure. Sale. Silencieuse. Efficace.

Un mainteneur npm s’est fait compromettre. L’attaquant a publié des versions infectées. Et pendant quelques heures — ça a suffi — des milliers de projets ont potentiellement récupéré un malware.

Pas besoin de cliquer sur un lien chelou. Pas besoin d’ouvrir une pièce jointe. Juste… installer une dépendance.

Franchement, c’est ça qui me dérange le plus : tu fais tout “bien”, et tu te fais quand même avoir.

Ce que faisait réellement la version piégée

On n’est pas sur un petit script marrant.

Le package ajoutait une dépendance obscure (plain-crypto-js) qui exécutait un script en postinstall. Et là, ça bascule.

Un RAT (Remote Access Trojan) était installé directement sur la machine.

En pratique, ça veut dire quoi ?

accès à ton système
exécution de commandes à distance
récupération de tokens (API, SSH, env…)
possibilité de rebondir sur d’autres machines

Et le pire — vraiment le pire — c’est que le malware pouvait s’auto-supprimer après coup. Donc même si tu regardes, tu ne vois rien.

Je l’ai déjà vu en audit : des machines propres en apparence… mais déjà vidées de leurs secrets.

Le piège classique côté dev (et je suis tombé dedans aussi)

Si tu bosses comme beaucoup de devs (moi inclus), tu fais confiance à ton écosystème.

Tu installes. Tu build. Tu avances.

Mais là, le problème vient de plus haut.

Ce n’est pas ton code.
Ce n’est pas une lib obscure.
C’est Axios.

Une des libs les plus utilisées en JS.

Donc forcément, tu ne te méfies pas.

Et c’est exactement là que l’attaque est intelligente — elle cible ta confiance, pas ta technique.

Comment savoir si tu t’es fait avoir

Concrètement, il y a une fenêtre précise.

Si tu as installé :

axios@1.14.1
ou axios@0.30.4

pendant la période de l’attaque, tu dois partir du principe que ton environnement est compromis.

Même si “tout a l’air normal”.

Tu peux checker rapidement :

npm ls axios

Et surtout :

npm ls plain-crypto-js

Si tu vois passer ce package, c’est mauvais signe.

Ce que je ferais à ta place (sans hésiter)

Pas de demi-mesure ici.

Si tu es touché :

tu considères ta machine compromise
tu rotates TOUS tes secrets
tu changes tes mots de passe
tu régénères tes clés SSH
tu rebuild ton environnement propre

Oui, c’est chiant. Oui, ça prend du temps.

Mais continuer comme si de rien n’était — c’est une erreur.

Je vois encore trop de devs espérer que “ça va passer”.

Non.

Le vrai problème : npm est une surface d’attaque énorme

On ne va pas se mentir.

Aujourd’hui, un projet JS classique, c’est quoi ?

Des centaines de dépendances. Parfois des milliers.

Tu ne les lis pas.
Tu ne les audits pas vraiment.
Tu leur fais confiance.

Et c’est normal — sinon tu ne codes plus.

Mais ça veut dire une chose simple : ta sécurité dépend de gens que tu ne connais pas.

Et parfois… ils se font compromettre.

Pourquoi j’ai écrit un livre là-dessus

Ce genre d’attaque, ce n’est pas un cas isolé.

C’est la norme qui arrive.

Les ransomwares, le phishing, les attaques supply chain… tout ça devient de plus en plus propre, de plus en plus invisible.

C’est exactement pour ça que j’ai écrit :

La CyberSécurité en 10 Chapitres — Antoine Masia

Pas un truc théorique.

Je parle de cas concrets — comme celui d’Axios — et surtout de comment réagir intelligemment (sans tomber dans la parano non plus).

Si tu veux comprendre vraiment ce qui se passe derrière ton terminal — et éviter de te faire surprendre — c’est clairement un bon point de départ.