Axios piégé sur npm : ce que l'attaque du 31 mars apprend aux PME
Une des bibliothèques JavaScript les plus utilisées a été publiée avec un cheval de Troie pendant trois heures. Ce qui s'est passé, et les questions à poser à votre prestataire.
Dans la nuit du 30 au 31 mars 2026, deux versions piégées d'axios, une bibliothèque que des millions de projets JavaScript utilisent pour dialoguer avec un serveur, ont été publiées sur npm, le grand magasin de paquets de l'écosystème. Pendant environ trois heures, toute installation non verrouillée pouvait déposer un cheval de Troie sur la machine du développeur ou sur le serveur de compilation. Vous n'avez sans doute jamais entendu parler d'axios. Votre logiciel, lui, l'utilise peut-être. Voici ce qu'il faut en retenir quand on dirige une entreprise qui fait développer ses outils.
Ce qui s'est passé
D'après Datadog Security Labs, les versions axios 1.14.1 et axios 0.30.4 ont été en ligne de 00 h 21 à 03 h 25 UTC le 31 mars, avant d'être retirées par npm. Elles ne contenaient presque rien de nouveau, sauf une dépendance ajoutée : plain-crypto-js, un nom choisi pour ressembler à une bibliothèque connue. Ce paquet exécutait un script au moment de l'installation, qui téléchargeait un logiciel d'accès à distance adapté au système : Windows, macOS ou Linux.
Malwarebytes précise que l'attaquant a publié ces versions avec les identifiants volés d'un des principaux mainteneurs du projet, et que le script effaçait ensuite ses traces : un contrôle rapide du dossier installé ne montrait rien d'anormal, et l'outil d'audit habituel de npm ne signalait rien. La bibliothèque est téléchargée, selon les sources, des dizaines de millions de fois par semaine.
Point important pour vous : selon Malwarebytes, les utilisateurs finaux d'une application construite avec axios ne sont pas exposés directement. Le danger se situe au moment de l'installation et de la compilation, c'est-à-dire sur les postes des développeurs et sur les serveurs qui fabriquent votre logiciel. C'est justement là que se trouvent les clés les plus précieuses : accès à l'hébergement, à la base de données, aux comptes de publication.
Pourquoi une PME est concernée
Un logiciel métier moderne, un site e-commerce ou une application mobile repose sur des centaines de briques open source écrites par d'autres. C'est normal et c'est sain : personne ne réécrit un client HTTP. Mais chaque brique est un fournisseur, et celui-ci peut être compromis. L'attaque d'axios ne visait pas une entreprise en particulier : elle visait tous ceux qui installeraient la mauvaise version pendant ces trois heures.
Concrètement, un prestataire qui a compilé votre application cette nuit-là sans précaution a pu exposer :
- les accès à votre serveur ou à votre hébergeur, s'ils étaient stockés sur la machine de compilation ;
- les clés de vos services tiers (paiement, envoi d'e-mails, stockage) ;
- les identifiants de publication de votre application sur les stores.
Les cinq questions à poser à votre prestataire
Vous n'avez pas à devenir expert. Vous avez le droit de poser des questions simples et d'obtenir des réponses claires.
- Nos versions de dépendances sont-elles verrouillées ? Un fichier de verrouillage (lockfile) fige la version exacte de chaque brique. Sans lui, chaque installation prend la dernière version publiée, y compris une version piégée.
- Une compilation a-t-elle eu lieu le 31 mars entre minuit et 3 h 30 (UTC) ? Si oui, a-t-on vérifié qu'elle n'a pas installé axios 1.14.1 ou 0.30.4 ?
- Attend-on quelques jours avant d'adopter une nouvelle version ? Datadog recommande ce délai de prudence : la plupart des paquets piégés sont repérés et retirés en quelques heures.
- Les secrets sont-ils séparés de la machine de compilation ? Moins une machine détient de clés, moins une intrusion coûte cher.
- Que fait-on si une machine est touchée ? La seule réponse correcte : on la considère comme compromise, on la réinstalle et on change tous les secrets qu'elle pouvait lire.
Ce qu'on fait chez nous
Nous livrons le code source et la documentation à nos clients, ce qui veut dire que la liste des dépendances est visible et vérifiable par n'importe qui, pas seulement par nous. Les versions sont verrouillées dans chaque projet, les mises à jour se font volontairement et non au fil de l'eau, et les clés de production ne vivent pas sur nos postes de développement. Ce n'est pas une garantie absolue, personne ne peut en donner une, mais c'est ce qui transforme une attaque comme celle-ci en vérification de dix minutes plutôt qu'en incident.
La maintenance que nous assurons après la livraison sert aussi à ça : surveiller les alertes de sécurité sur les briques utilisées et appliquer les correctifs, avec une réponse sous 24 heures ouvrées. Vous trouverez le détail de nos offres de développement logiciel et leurs prix « à partir de » sur la page Tarifs.
À retenir
Cette attaque n'a rien d'exotique : elle reproduit un schéma qui se répète depuis plusieurs années dans l'écosystème JavaScript, avec un compte de mainteneur détourné et une version empoisonnée publiée au milieu de la nuit. Ce qui change, c'est l'ampleur de la cible. La bonne réaction pour un dirigeant n'est pas de bannir l'open source, mais de s'assurer que son logiciel est fabriqué avec des versions figées, des secrets bien rangés et une procédure claire quand une alerte tombe. Si vous ne savez pas comment votre application est construite, c'est le bon moment pour poser la question, à nous ou à votre prestataire actuel, lors d'un rendez-vous de 30 minutes.