Attaque supply chain sur npm : le paquet Axios compromis par des hackers nord-coréens

Deux publications sur npm, et c’est toute une partie de l’écosystème JavaScript qui a retenu son souffle. Le 31 mars 2026, des attaquants ont réussi à pousser des versions piégées du paquet axios, l’un des clients HTTP les plus utilisés, en compromettant le compte npm d’un mainteneur. Les versions malveillantes identifiées, 1.14.1 et 0.30.4, sont restées disponibles environ trois heures avant d’être retirées.

Le mécanisme est typique d’une attaque de chaîne d’approvisionnement, mais avec un niveau de préparation qui inquiète. Une dépendance ajoutée en douce, plain-crypto-js, déclenchait un script post-installation pour récupérer des charges utiles et installer une porte dérobée sur Windows, macOS et Linux. Google Threat Intelligence Group attribue l’opération à UNC1069, un acteur lié à la Corée du Nord, connu pour des campagnes à motivation financière.

UNC1069 vise Axios, plus de 100 millions de téléchargements hebdomadaires

Le point qui change l’échelle, c’est la popularité d’axios. Le paquet dépasse les 100 millions de téléchargements hebdomadaires selon les éléments communiqués par des analystes du secteur, ce qui veut dire une présence massive dans des applications web, des backends Node. js, des scripts internes d’entreprise, et des pipelines CI. Même si la fenêtre d’exposition a été courte, la surface potentielle est immense, parce que l’installation de dépendances est automatisée partout.

L’attribution à UNC1069 s’appuie sur des recoupements de code malveillant et d’infrastructure de commande et contrôle. On parle d’un groupe actif depuis au moins 2018, décrit comme financièrement motivé, avec un historique de ciblage de la crypto, de la DeFi, de développeurs et de fonds d’investissement. Là, l’intérêt n’est pas de casser un site web visible, c’est de s’installer discrètement dans des environnements de développement et de production, là où transitent clés, jetons et secrets.

John Hultquist, analyste en chef chez Google Threat Intelligence Group, résume l’idée sans détour, les acteurs nord-coréens ont une expérience profonde des attaques de chaîne d’approvisionnement et les ont déjà utilisées pour voler des crypto-actifs. Ce n’est pas une phrase pour faire peur, c’est une lecture pragmatique du modèle économique, tu compromises un outil central, tu récupères des accès, puis tu monétises plus tard, parfois longtemps après l’incident initial.

Tomislav Pricing, architecte logiciel chez ReversingLabs, insiste sur la sophistication opérationnelle, identifiants de mainteneur compromis, charges utiles prêtes pour trois systèmes, deux branches de publication touchées en moins de 40 minutes, et des mécanismes pensés pour compliquer l’analyse. Là où beaucoup d’attaques se font repérer par du code grossier, celle-ci cherche à rester invisible, avec une injection minimale et un comportement malveillant repoussé dans une dépendance et des téléchargements distants.

Les versions 1.14.1 et 0.30.4 ont ajouté plain-crypto-js

Les versions compromises d’axios, 1.14.1 et 0.30.4, avaient un point commun, l’ajout d’une dépendance, plain-crypto-js. Dit comme ça, ça ressemble à un paquet crypto banal, le genre de nom qui ne déclenche pas d’alerte immédiate. C’est précisément le but, se fondre dans le bruit des milliers de dépendances qui composent un projet JavaScript moderne, où personne ne lit chaque diff de chaque version.

Le cur de l’attaque passait par un script post-install, une fonctionnalité npm qui permet d’exécuter du code automatiquement au moment de l’installation. Dans un contexte CI, ça tourne sans interaction humaine, sur des runners qui ont parfois accès à des variables d’environnement sensibles. Les chercheurs expliquent que le script tentait de télécharger et d’exécuter des charges utiles supplémentaires depuis une infrastructure contrôlée par l’attaquant, ce qui externalise l’essentiel du comportement malveillant.

Ce détail compte, parce que l’injection visible dans le paquet principal peut rester minimale. Un développeur qui inspecte vite fait le code d’axios peut ne rien voir d’évident. La charge utile arrive après, depuis l’extérieur. Et si l’infrastructure est coupée, l’analyse devient plus difficile, tu te retrouves avec un comportement qui dépend de ce qui était servi à un instant T, et pas uniquement d’un artefact stocké sur npm.

Il y a aussi un angle très concret, la gestion des versions. Dans beaucoup d’organisations, les dépendances sont mises à jour automatiquement via des bots, ou au fil de l’eau quand un développeur lance un install. Une version mineure qui paraît anodine peut se retrouver déployée dans des environnements de test et parfois en production. Dans ce type d’incident, la question n’est pas seulement « qui a installé », c’est « où a-t-on installé », sur quelles machines, avec quels droits, et quelles clés étaient accessibles à ce moment-là.

WAVESHAPER. V2 a ciblé macOS, Windows et Linux

Les charges utiles servies par l’infrastructure de l’attaquant menaient à une porte dérobée suivie sous le nom WAVESHAPER. V2. Google la décrit comme une backdoor écrite en C++ ciblant notamment macOS, capable de collecter des informations système, d’énumérer des répertoires et d’exécuter des charges additionnelles. Le point important, c’est le côté modulable, tu installes un premier étage, puis tu fais évoluer la suite selon la valeur de la victime.

Le caractère multiplateforme est central. Les environnements de développement modernes mélangent macOS pour les développeurs, Linux sur les serveurs et runners CI, et Windows dans beaucoup d’entreprises. Préparer des payloads pour les trois systèmes, c’est un investissement, mais ça augmente les chances de tomber sur une machine utile. Et dans une attaque de chaîne d’approvisionnement, l’attaquant ne choisit pas la victime une par une, il arrose large puis il trie.

Concrètement, une backdoor de ce type peut servir à voler des secrets, récupérer des jetons d’accès, ou préparer un mouvement latéral. Les sources évoquent explicitement la possibilité de vol de données sensibles et de déplacement dans le réseau. Dans une chaîne CI, ça peut vouloir dire accéder à des clés de signature, à des tokens de publication, ou à des identifiants cloud. À partir de là, tu ne compromets plus seulement un poste, tu peux toucher des dépôts, des artefacts, voire d’autres paquets.

Un point qui mérite une nuance, tout le monde ne sera pas touché de la même façon. Installer une version compromise sur une machine isolée sans secrets n’a pas le même impact que sur un runner connecté à des environnements de production. Mais les recommandations des analystes sont claires, si tu as installé les versions concernées, tu dois considérer le système comme compromis. Et ça, c’est coûteux, parce que ça implique rotation de secrets, audit, et parfois reconstruction complète.

Le jeton npm a contourné le trusted publishing de GitHub

L’un des aspects les plus instructifs de l’affaire, c’est le contournement des garde-fous modernes. Les chercheurs expliquent que les attaquants ont évité le workflow de publication de confiance de GitHub en utilisant un jeton npm longue durée associé au compte du mainteneur. En clair, même si un projet a mis en place des pratiques de publication plus sûres, un token valide qui traîne suffit parfois à publier directement sur npm, sans les contrôles de provenance attendus.

Ce n’est pas un détail technique réservé aux spécialistes, c’est une leçon de gouvernance. Les tokens longue durée sont pratiques, mais ils deviennent des clés maîtresses. S’ils sont exfiltrés, stockés dans un endroit faible, ou réutilisés trop longtemps, l’attaquant n’a même pas besoin de casser la chaîne CI, il publie. Et dans l’écosystème npm, publier une version d’un paquet aussi central que axios, c’est comme déposer un micro dans des milliers d’entreprises.

Les attaquants ont aussi travaillé la crédibilité de leur dépendance. Une version bénigne de plain-crypto-js aurait été publiée plus tôt pour établir un historique « normal » et réduire les soupçons. C’est une tactique classique, tu crées un paquet qui ressemble à une copie propre, tu attends, puis tu glisses des changements minimes. Dans la précipitation, beaucoup d’outils automatisés se contentent de vérifier que le paquet existe et qu’il n’est pas nouveau de cinq minutes.

À ce stade, il faut aussi pointer une limite, l’écosystème dépend beaucoup de bénévoles et de mainteneurs qui n’ont pas toujours les moyens d’une entreprise. On peut exiger des pratiques parfaites, mais la réalité, c’est que des bibliothèques critiques reposent sur peu de personnes. Tant que le modèle économique de l’open source ne finance pas davantage la sécurité opérationnelle, on aura ce type de point de rupture, et pas seulement sur axios.

npm a retiré les paquets en trois heures, les équipes doivent reconstruire

La réaction a été rapide, les versions malveillantes ont été retirées du registre npm après environ trois heures. Selon les éléments rapportés par des acteurs de la réponse à incident, npm a aussi placé une mise en sécurité sur plain-crypto-js et a remplacé la dépendance par un « security-holder » stub, une sorte de paquet neutralisé destiné à empêcher une réutilisation immédiate du nom. C’est une mesure d’endiguement, pas une réparation magique.

Le problème, c’est ce qui se passe pendant ces trois heures. Dans un monde où les pipelines tournent en continu, ça peut suffire pour que des milliers d’installations se produisent. Et même si une partie des environnements n’exécute pas les scripts post-install, beaucoup le font par défaut. Les recommandations des analystes vont loin, rotation de tous les identifiants, reconstruction depuis des snapshots propres, et examen des machines comme si un accès à distance avait été obtenu.

Un autre détail technique illustre la volonté de tromper les défenseurs. La version malveillante de la dépendance, identifiée comme 4.2.1, aurait cherché à se faire passer pour 4.2.0 après exécution, pour donner l’illusion que rien n’a été installé. Ce type de camouflage complique les inventaires basés sur les versions déclarées. Et si tu fais de la réponse à incident, tu sais que le temps perdu à cause d’un faux signal coûte cher.

Sur le plan des conséquences, il faut s’attendre à des audits de dépendances plus stricts, mais aussi à des frictions. Verrouiller les versions, bloquer les scripts post-install, imposer des proxies de paquets internes, tout ça sécurise, mais ralentit les équipes. Et il y a une critique à formuler, beaucoup d’organisations découvrent ces mesures seulement après une alerte médiatisée. La sécurité de la chaîne logicielle n’est pas un patch, c’est une discipline, et elle demande du budget, du temps, et des arbitrages parfois impopulaires.