Pourquoi l'attaque supply chain sur Axios est un cas d'école
En mars 2026, la bibliothèque JavaScript Axios a été victime d'une attaque supply chain qui a permis de compromettre des milliers de machines de développeurs en un temps record, sans déclencher aucune alerte.
Fin mars 2026, le compte npm du mainteneur principal d'Axios a été compromis. Axios est une bibliothèque JavaScript téléchargée des dizaines de millions de fois par semaine, présente dans quasiment tous les projets qui ont besoin de communiquer avec internet ou avec un autre système : récupération de données, envoi des informations, consultation d'une API, etc. Axios est dans beaucoup de projets une brique de base et c'est précisément pour cette raison qu'elle a été prise pour cible.
Décryptage d'une attaque éclair
⏩ En moins de 40 minutes, deux versions malveillantes ont été publiées à travers une méthode singulière : plutôt que de modifier directement le code d'Axios, ce qui aurait pu faire émettre des soupçons et être détecté rapidement, les auteurs de l'attaque ont introduit une dépendance fantôme, plain-crypto-js. Dans l'écosystème JavaScript, une dépendance est un module externe dont un projet a besoin pour fonctionner. Et comme les projets en embarquent souvent des dizaines, parfois des centaines de dépendances, très rares sont les équipes qui les inspectent une à une. C'est précisément sur ce point et cette confiance aveugle accordée aux dépendances non testées que repose l'attaque.
plain-crypto-js n'apparaît jamais dans le code de l'application finale. Son seul rôle est de s'exécuter au moment où le développeur installe la bibliothèque sur sa machine, une opération aussi banale que de télécharger une mise à jour. C'est l'image du cheval de Troie appliquée au logiciel : on ne force pas la porte, les pris pour cibles fontt confiance à un objet qui n'est pas identifié comme inquiétant et ces derniers le font entrer volontairement dans la ville, sans qu'aucune alerte ne soit donnée.
Une fois déclenché, ce programme malveillant contacte silencieusement un serveur distant, télécharge une charge utile adaptée au système d'exploitation (Mac, Windows ou Linux) puis s'auto-détruit pour ne laisser aucune trace. Et voila, en moins de deux secondes, sans la moindre interaction visible pour le développeur, la machine de ce dernier est compromise sans avoir éveillé ses soupçons.
Pourquoi cette attaque est-elle aussi grave qu'ingénieuse ?
😵 La cible n'est pas l'utilisateur final de l'application mais le développeur lui-même qui a accès aux codes sources des projets sur lesquels il travaille, aux identifiants et clés d'accès qui permettent de se connecter aux serveurs de production, aux environnements de déploiement, aux dépôts Git privés, parfois aux systèmes de ses clients. Compromettre sa machine, c'est potentiellement ouvrir une porte sur l'ensemble de l'infrastructure de l'entreprise ciblée sans jamais avoir directement touché à un seul des propres systèmes de cette dernière.
☠️ La fenêtre d'exposition ne dure que 2 à 3 heures avant que les versions malveillantes soient retirées mais Axios étant téléchargée en continu à toute heure dans le monde entier , dans les pipelines d'intégration continue, sur les postes des développeurs, dans les environnements de build automatisés, etc., des milliers de machines ont pu être touchées pendant ce laps de temps sans que personne n'ait eu le temps de réagir.
Qui est derrière cette attaque ?
L'attribution a été formellement établie par Google Threat Intelligence Group (GTIG) et Mandiant, qui pointent vers UNC1069, un groupe lié à la Corée du Nord, actif depuis au moins 2018. Ce n'est pas un collectif de hackers opportunistes : UNC1069 est un acteur étatique dont les opérations sont financièrement motivées, ciblant principalement les entreprises du secteur des cryptomonnaies, les développeurs de logiciels et les fonds d'investissement. Ses attaques sont documentées, récurrentes et d'une sophistication croissante.
Dans le cas d'Axios, la dépendance malveillante avait été préparée 18 heures à l'avance , avec trois charges utiles distinctes selon le système d'exploitation. Ce niveau de préparation prouve que l'opération était planifiée et ciblée.
Pourquoi ce vecteur est particulièrement redoutable
C'est ce qu'on appelle une attaque supply chain : on ne s'attaque pas au coffre-fort, on s'attaque à la personne qui apporte l'argent. Plutôt que de s'en prendre directement à une entreprise bien protégée, on compromet un composant de confiance qu'elle utilise et on se laisse transporter jusqu'à elle.
L'effet de levier est considérable. Un seul composant compromis, embarqué dans des milliers de projets à travers le monde, permet d'atteindre simultanément des milliers de cibles sans jamais les attaquer directement. Et plus le composant est populaire, plus la portée d'atteinte est large. Avec 100 millions de téléchargements par semaine, Axios était une cible de choix.
Ce vecteur particulièrement insidieux car il contourne l'ensemble des mesures de sécurité habituelles. Pare-feu, analyses de vulnérabilités, politiques d'accès, etc. : tout cela ne sert à rien si la compromission a eu lieu en amont, au moment de l'installation d'une dépendance sur le poste du développeur. On peut avoir investi massivement en cybersécurité et se retrouver exposé par une mise à jour de routine qu'aucune alarme n'a signalée.
Les meilleures pratiques pour se protéger
La sensibilisation avant tout
Une équipe qui ignore que ce vecteur existe est une équipe exposée, indépendamment de son niveau de maturité en cybersécurité. Le développeur qui met à jour chaque nouvelle version de chaque dépendance sans se poser de questions est une porte d'entrée et si personne ne lui a expliqué que ce risque existe, il n'a aucune raison de s'en méfier. Ce n'est pas une question de compétence : c'est une question de sensibilisation.
Elle doit toucher deux niveaux. Les équipes techniques d'abord : comprendre que l'installation d'une dépendance est un acte qui a des conséquences de sécurité, pas seulement fonctionnelles. Les décideurs ensuite : comprendre que la sécurité de la supply chain ne se résume pas à un antivirus ou un pare-feu, qu'elle implique des choix organisationnels et budgétaires, et que sans leur arbitrage, les équipes techniques ne peuvent pas avancer.
Mettre en place des garde-fous concrets
Ne pas mettre à jour n'importe quoi, n'importe quand, n'importe comment. Cela implique de définir des règles claires au niveau de l'organisation : une liste blanche de dépendances autorisées, quels composants peuvent entrer dans les projets, dans quelles versions et quelles sont les versions immuables à destination de l'équipe technique. Concrètement, cela signifie qu'une fois qu'une version d'une dépendance a été validée et approuvée par l'équipe, elle ne change plus sans décision explicite. On ne suit pas automatiquement les nouvelles versions publiées sur le registre public. Cela ralentit les cycles de développement mais réduit drastiquement la surface d'exposition.
En effet, GitLab permet de mettre en place un registre privé qui joue le rôle de miroir interne : 1. les versions peuvent y être analysées ; 2. Celles qu'on a identifiées de sûres y sont archivées ; 3. On brief ensuite les développeurs pour n'installer et n'utiliser que ces versions considérées sans danger contrairement à celles accessibles depuis des registres publics.
➡️ C'est une mesure concrète, accessible pour la plupart des équipes, qui change réellement la donne en cas d'incident sur un package public.
Se protéger a un coût : avancer moins vite pour avancer plus sûr
C'est un parti pris : la sécurité de la supply chain ne s'improvise pas et a bel et bien un coût réel : en temps, en organisation, en infrastructure. ➡️ Chaque organisation doit faire cet arbitrage selon ses contraintes, son secteur, son niveau d'exposition. Il n'y a pas de réponse universelle. ➡️ Mais cet arbitrage doit être conscient. Plus une base de code embarque de dépendances, plus sa surface d'exposition grandit. Il suffit d'une dépendance compromise sur mille pour compromettre l'ensemble. Faire le choix d'avancer moins vite pour avancer plus sûr, c'est accepter une contrainte aujourd'hui pour éviter une crise demain. Ne pas faire ce choix, c'est aussi une décision, à condition de la prendre en connaissance de cause, et non par défaut.
Un choix qui appartient aux décideurs
La sensibilisation et les garde-fous techniques ne suffisent pas si la décision de les mettre en place ne vient pas du bon niveau. Définir une politique de dépendances, allouer du temps pour la maintenir, investir dans un registre privé, ce sont des décisions qui engagent l'organisation, pas seulement l'équipe technique. Face à ce risque, la première étape est de mettre le sujet sur la table avec les bons interlocuteurs et de s'assurer que les décideurs comprennent ce qu'ils arbitrent réellement.
Pour aller plus loin, la CISA et le NIST ont publié conjointement un guide de référence sur la défense contre les attaques supply chain, qui reste une ressource solide pour structurer une approche organisationnelle sur le sujet.
Vérifier l'exposition de vos machines
Si vos projets clients ou internes utilisent Node.js/npm, la recommandation est claire : si les versions 1.14.1 ou 0.30.4 d'Axios ont été installées entre le 31 mars et le 1er avril 2026, la machine concernée est à considérer comme compromise. Il convient de faire tourner les identifiants et clés d'accès, et selon le niveau d'exposition, d'envisager une réinstallation complète du poste.
L'équipe Sigilence est à votre écoute si vous pensez être concernés 😉