Le piratage d'axios : comment un seul développeur infecté a exposé 174 000 projets
Lire la version audio
L'article sur les API expliquait comment une application communique avec un service extérieur. Axios est justement l'un des outils les plus utilisés au monde pour faire exactement ça en JavaScript, avec une centaine de millions de téléchargements chaque semaine. Le 31 mars 2026, cet outil s'est brièvement transformé en logiciel espion, pour tous ceux qui l'ont installé pendant une fenêtre de trois heures.
Ce qui s'est passé
Le 31 mars 2026, des attaquants ont publié deux versions piégées d'axios (1.14.1 et 0.30.4) sur npm, le principal registre de logiciels JavaScript. Ces versions installaient silencieusement, via une dépendance cachée nommée "plain-crypto-js" imitant le nom d'une bibliothèque légitime existante, un logiciel espion capable de fonctionner sur Windows, macOS et Linux. Le chercheur en sécurité Feross Aboukhadijeh a donné l'alerte publiquement, et npm a retiré les versions piégées après environ trois heures de diffusion active. Axios comptant plus de 174 000 projets qui en dépendent directement, l'ampleur potentielle de l'exposition, même sur une fenêtre aussi courte, reste considérable.
Comment le compte du mainteneur lui-même a été piraté
L'origine de cette compromission tient à une ironie directe avec l'article sur l'ingénierie sociale : l'ordinateur personnel du responsable principal d'axios a d'abord été compromis par une campagne d'ingénierie sociale ciblée, installant lui-même un logiciel espion qui a permis de récupérer les identifiants utilisés pour publier de nouvelles versions du logiciel. Un logiciel espion a donc servi à en diffuser un autre, à une toute autre échelle : un développeur individuel piégé personnellement a suffi à ouvrir un accès vers des centaines de milliers de projets qui n'avaient, eux, absolument rien fait de mal.
Le mécanisme de la chaîne d'approvisionnement logicielle, version développeur
Installer axios dans un projet ne demande qu'une simple commande : les outils de développement téléchargent alors automatiquement le logiciel et l'ensemble de ses propres dépendances, sans qu'un développeur ne relise habituellement chaque ligne de code ajoutée de cette façon. C'est exactement le même mécanisme d'attaque de la chaîne d'approvisionnement déjà rencontré avec la brèche Klue, appliqué cette fois non pas à une intégration SaaS entre entreprises, mais directement à l'écosystème des briques logicielles open source sur lesquelles reposent la quasi-totalité des applications modernes.
Pourquoi trois heures ont suffi à un impact énorme
La plupart des registres de logiciels open source, npm compris, permettent à une nouvelle version d'un projet de devenir immédiatement installable par n'importe qui dans le monde, dès sa publication, sans délai de revue obligatoire. Cette rapidité, précieuse pour corriger vite une faille légitime, devient une faiblesse structurelle le jour où c'est une version malveillante qui est publiée : le temps de réaction de la communauté devient alors la seule vraie limite à l'ampleur de la diffusion.
Ce que ça change, concrètement
Pour un développeur, cet incident renforce l'intérêt de figer précisément les versions des dépendances utilisées dans un projet plutôt que de toujours récupérer automatiquement la toute dernière version disponible, et de revoir les mises à jour de dépendances plutôt que de les accepter par réflexe. Pour tout le monde, ça confirme qu'un logiciel "de confiance" n'est jamais une garantie figée dans le temps : cette confiance repose, in fine, sur la sécurité personnelle d'un nombre parfois restreint de personnes qui en détiennent les clés de publication, un rappel que la chaîne d'approvisionnement logicielle mérite la même vigilance que n'importe quel autre maillon faible déjà évoqué sur ce site.