Axios a fait des siennes pendant trois heures, sans que ses 100 millions de téléchargements hebdomadaires ne s'en aperçoivent

Principaux enseignements

• Les versions malveillantes d'Axios n'ont été disponibles que pendant environ trois heures ; les installations effectuées avant leur détection n'ont donc pas pu bénéficier des mesures de protection mises en place à la suite de l'avis de sécurité.
• Le nombre de téléchargements reflète l'adoption, et non l'examen, et Axios peut être installé via des paquets qu'une équipe n'a jamais sélectionnés.
• Plusieurs mesures de contrôle auraient pu briser cette chaîne, qu'il s'agisse d'installations verrouillées, de scripts d'installation bloqués, de fenêtres de quarantaine, de vérifications de provenance ou encore de filtrage du registre.
• Les mesures préventives les plus efficaces interviennent au moment de l'installation ou avant celle-ci, et c'est justement dans ce domaine que de nombreuses équipes ont le moins investi.

Deux versions malveillantes d’axios ont été mises en ligne le 31 mars 2026 et sont restées accessibles pendant environ trois heures avant d’être retirées. Au cours de cette période, elles se sont discrètement glissées dans les arborescences de dépendances d’une grande partie de l’ écosystème JavaScript, et presque aucune des personnes qui les ont installées n’avait les moyens de s’en rendre compte.

Personne au sein du projet ne les a publiées. Ces versions ont été publiées à partir d’un compte de responsable piraté, manuellement à l’aide d’un jeton à longue durée de vie volé qui a contourné le pipeline d’intégration continue (CI) du projet ; elles apparaissaient donc sur le registre comme des versions axios tout à fait ordinaires. Les numéros de version semblaient normaux. npm audit n’a rien signalé pendant la première partie de la fenêtre, car l’avis qui allait finalement décrire l’incident n’avait pas encore été rédigé.

Trois heures au cœur d'une attaque visant la chaîne d'approvisionnement d'npm

Trois heures, ce n'est pas long. Ce n'est pas assez long pour que la plupart des équipes remarquent qu'une nouvelle version a été publiée, et encore moins pour qu'elles puissent l'évaluer.

Le schéma général d'une faille de sécurité côté publication est bien documenté, et axios a suivi ce schéma en y ajoutant une couche supplémentaire qui fait défaut à la version générique. Les deux versions ont intégré une toute nouvelle dépendance appelée plain-crypto-js, dont la seule raison d’être était d’exécuter une charge utile à partir d’un hook post-installation. Une version leurre « propre » de ce paquet avait été mise en ligne environ 18 heures plus tôt, ce qui a permis de faire passer la version malveillante suivante pour quelque chose de moins nouveau, et les fichiers source d’axios eux-mêmes n’ont jamais été modifiés. L'ingénierie sociale a d’abord permis au pirate d’accéder à la machine du responsable de maintenance, ce qui lui a donné les droits de publication.

La phase la plus intéressante est celle de la propagation. Entre la publication et la découverte, le chemin d'installation par défaut de npm ne demande jamais à un paquet de prouver que l'artefact transmis a bien été compilé à partir du code source et selon le workflow qu'il prétend utiliser. C'est précisément cette faille qui constitue la fenêtre d'attaque.

Wiz a constaté que le logiciel malveillant s'exécutait effectivement dans environ 3 % des environnements affectés répertoriés dans ses données télémétriques, et les chercheurs ont estimé séparément que la fenêtre d’exposition à environ 600 000 téléchargements. Ces deux chiffres provenant de populations différentes, leur multiplication ne donne pas un nombre réel de victimes. Considérés conjointement, ils indiquent toutefois une exécution confirmée de la charge utile au cours d’une fenêtre d’exposition très courte, et non pas simplement la présence de fichiers sur le disque.

Retour à la réalité : Le retrait d’une version malveillante empêche toute nouvelle installation. Cela n’a toutefois aucun effet sur les machines qui l’ont déjà exécutée, les jetons qui ont déjà été exfiltrés, ni sur les images de conteneurs déjà construites et déployées, dans lesquelles le code malveillant est intégré.

Pourquoi 100 millions de téléchargements hebdomadaires ne constituent pas un indicateur de sécurité

Le principe tacite qui sous-tend le choix de dépendances populaires est que la popularité est synonyme de contrôle rigoureux. Plus il y a d'yeux qui les examinent, moins il y a de bugs : c'est tout le raisonnement.

C'est un argument valable en ce qui concerne le code source. Mais il ne tient pas la route en matière d'intégrité de la publication, car l'attention se porte sur le dépôt alors que l'attaque se produit au niveau du registre. Il s'agit de deux entités distinctes, et npm n'exige pas qu'elles correspondent. De nombreux scanners étaient en alerte cette nuit-là et plusieurs d'entre eux ont signalé la publication en quelques minutes. Rien dans le chemin d'installation par défaut ne les attend.

Il y a un deuxième problème, et c’est celui-là qui rend ce genre d’incident si pénible à gérer. Certaines équipes n’ont jamais installé Axios directement. Elles ont installé un composant qui en a installé un autre, lequel a à son tour installé Axios.

Une étuded’Endor Labs citée dans le « Top 10 » de l’OWASP consacré aux logiciels libres estime à environ 95 % la part des vulnérabilités présentes dans les dépendances indirectes à environ 95 % plutôt que dans les paquets qu’une équipe a délibérément choisis. Ce chiffre prend en compte les vulnérabilités connues plutôt que les logiciels malveillants, mais il montre à quel point une grande partie du graphe de dépendances se situe en dehors des paquets que les développeurs sélectionnent délibérément, et ces graphes ne se sont pas simplifiés. Lorsque le paquet compromis se trouve quatre niveaux plus bas dans un graphe que personne n’a réellement lu, la question « Utilisons-nous même axios ? » devient étonnamment difficile à répondre rapidement.

npm ls axios –all

npm ls plain-crypto-js –all

Testez-les sur tous les dépôts, pas seulement ceux dont vous vous souvenez avoir ajouté un client HTTP. Si l'un d'entre eux renvoie axios 1.14.1 ou 0.30.4, ou plain-crypto-js 4.2.1, considérez l'hôte comme compromis et revenez à axios 1.14.0 ou 0.30.3, puis renouvelez tous les identifiants auxquels cet hôte pourrait accéder.

Que cherchait donc un acteur étatique à faire avec un client HTTP ?

Le groupe Threat Intelligence de Google a attribué la violation d'Axios à UNC1069, un acteur lié à la Corée du Nord et motivé par l'appât du gain, connu pour avoir déjà dérobé des fonds sur des plateformes d'échange de cryptomonnaies. Microsoft suit les activités qui se recoupent sous le nom de « Sapphire Sleet », tandis que d'autres chercheurs associent ces activités à des noms tels que « BlueNoroff » et « Stardust Chollima ». Un client HTTP peut sembler une cible étrange pour un groupe spécialisé dans ce type d'activités, jusqu'à ce que l'on réfléchisse à ce que son piratage peut rapporter.

Les machines des développeurs et les agents de compilation, à grande échelle – et ces machines contiennent des identifiants de rôles cloud, des jetons de registre, des clés de signature et le code source de produits qui n’ont pas encore été commercialisés. Cibler les outils de développement plutôt que directement l’environnement de production est une stratégie qui se retrouve également dans les précédentes campagnes npm, et elle fonctionne parce que les postes de travail des développeurs et les agents de compilation détiennent des identifiants offrant un accès en aval exceptionnellement étendu.

Le rapport 2026 de Verizon sur les enquêtes relatives aux fuites de données a révélé que l’exploitation des vulnérabilités a supplanté le vol d’identifiants en tant que principal vecteur d’accès initial, représentant 31 % des violations contre 13 % pour l’utilisation abusive d’identifiants. Les identifiants n’ont toutefois pas perdu de leur importance. Ils restent l’un des éléments les plus courants une fois l’intrusion en cours, et une compromission permettant d’extraire des jetons de milliers d’environnements de développement est exactement le genre d’opération qui alimente ce stock.

Shai-Hulud et l'évolution vers les logiciels malveillants à propagation autonome

Axios n'était qu'une publication isolée. Les campagnes de vers informatiques sont d'un tout autre ordre.

Shai-Hulud a ouvert la voie en septembre 2025 avec un code malveillant qui, une fois exécuté dans un environnement de développement ou d’intégration continue (CI), recherche des informations confidentielles, identifie les jetons de publication npm et les utilise pour s’introduire dans d’autres paquets. Une campagne connexe, connue sous le nom de Mini Shai-Hulud , a débuté le 29 avril 2026 et s’est poursuivie avec deux vagues supplémentaires en mai. En cours de route, TeamPCP a publié le code source du ver sur GitHub, et ce n’est pas le genre de génie qui se remet dans sa bouteille.

Le mécanisme est plus important que l'image de marque. Une campagne à propagation automatique transforme chaque victime disposant de droits de publication exploitables en un nouveau point de diffusion ; ainsi, le nombre de paquets affectés ne cesse d'augmenter sans que l'attaquant n'ait à lever le petit doigt.

Attention : l'analyse secrète est une arme à double tranchant. Plusieurs campagnes de vers ont intégré des scanners secrets disponibles dans le commerce, tels que TruffleHog, pour rechercher des identifiants sur les hôtes infectés. Il s'agit des mêmes outils que ceux utilisés par les défenseurs, mais orientés dans la direction opposée.

Cette courbe de croissance justifie le recours à des points de contrôle qui ne reposent pas sur la connaissance préalable des paquets compromis. Le filtrage des paquets avant leur résolution et la vérification des artefacts publiés par rapport au code source validé permettent de détecter des catégories entières de compromissions sans attendre la publication d’un avis de sécurité. C’est le raisonnement qui sous-tend SecureChain pour npm.

Mastra et jscrambler ont perpétué la tradition

Deux incidents survenus par la suite en 2026 ont clairement montré que celui de mars n’était pas un cas isolé. La prise de contrôle du package Mastra AI le 17 juin et la compromission de jscrambler le 11 juillet ont toutes deux été rendues possibles par un accès côté publication plutôt que par une vulnérabilité présente dans le code d’un utilisateur.

Microsoft a attribué la compromission de Mastra à « Sapphire Sleet », nom qu’il donne à l’activité que Google suit sous le nom d’UNC1069. Environ onze semaines après l’incident rapporté par Axios, ce même groupe a récidivé en utilisant un scénario d’attaque très similaire. Un ancien compte de contributeur, qui disposait toujours de droits de publication dans l’espace @mastra, a été utilisé pour republier plus de 140 paquets. La seule modification apportée à chacun d’entre eux consistait en l’ajout d’une dépendance appelée easy-day-js, une bibliothèque similaire à dayjs contenant un hook post-installation malveillant. Le code de la bibliothèque n’a jamais été modifié, ce qui correspond exactement à ce qui s’était produit avec axios.

Sonatype a signalé plus de 454 600 nouveaux paquets open source malveillants sur npm, PyPI et d’autres registres rien qu’en 2025 ; ce volume n’est donc pas une nouveauté. Ce que cette vague récente met en évidence, c’est la rapidité avec laquelle un accès de publication compromis transforme ce volume en une menace qui parvient jusqu’à la phase de compilation.

Qu'est-ce qui aurait réellement pu l'empêcher ?

Voici six mesures de contrôle potentielles, qui ont été testées de manière rigoureuse face à une attaque de type « compromise » d'une durée de trois heures du côté de la publication.

–ignore-scripts a fait ses preuves, et l’écosystème s’y est depuis adapté. npm 12 a été lancé le 8 juillet 2026, avec les scripts d’installation des dépendances désactivés par défaut, y compris le node-gyp rebuild qu’un simple fichier binding.gyp déclenchait auparavant ; npm 12 bloque donc cette charge utile sans que personne n’ait besoin de se souvenir d’un indicateur. Les dépendances qui ont réellement besoin de scripts d’installation ou de compilation native doivent désormais être approuvées explicitement, ce qui mérite d’être examiné attentivement avant qu’une mise à jour ne vienne perturber discrètement un pipeline.

Ce n'est toujours pas une solution définitive : un code malveillant présent dans le corps du module s'exécute dès qu'un élément importe le paquet, que le script soit bloqué ou non. Le compromission de jscrambler en juillet en est l’illustration la plus claire. Les premières versions malveillantes s’exécutaient à partir d’un hook de préinstallation, puis, au cours de la même fenêtre de publication de trois heures, l’attaquant a intégré le même dropper dans le code même du paquet afin qu’il se déclenche lors de l’importation du paquet ou de l’exécution de son interface CLI. Le blocage des scripts d’installation est nécessaire. Mais il n’est pas suffisant.

La discipline relative aux fichiers de verrouillage nécessite une mise en garde plus importante, car il s'agit de la mesure de contrôle que la plupart des équipes considèrent comme déjà mise en place.

Attention : Une plage de caractères telle que ^1.7.0 dans le fichier package.json peut très bien se traduire par une version de correctif malveillante si rien ne la verrouille. Un fichier de verrouillage validé empêche cela, et npm ci est la méthode la plus stricte pour effectuer une installation à partir de ce fichier, car il refuse de s’exécuter lorsque le fichier de verrouillage et le fichier package.json ne concordent pas, au lieu de modifier discrètement la résolution. Cette protection disparaît dès que le fichier de verrouillage est régénéré ou mis à jour vers une version contenant la faille. De nombreux pipelines négligent au moins l’un de ces éléments.

La traçabilité s'avère utile dans ce cas précis, et face à ce type de défaillance, elle fait ses preuves.

Le saviez-vous ? npm prend en charge l'attestation de provenance basée sur Sigstore pour les paquets publiés depuis l'environnement d'intégration continue (CI), et vous pouvez vérifier ce dont vous disposez déjà à l'aide d'une seule commande : npm audit signatures.

Il convient de préciser ce que cela prouve. La provenance permet de vérifier qu’un artefact provient bien de la source et du processus de compilation qu’il prétend, ce qui est une question différente et bien plus facile à trancher que celle de savoir si le code qu’il contient est malveillant. Dans le cas d’axios, cela aurait été utile, car la dernière version 1.x saine comportait une information de provenance, contrairement à la version malveillante, qui avait été déployée manuellement à l’aide d’un jeton volé plutôt que via le workflow de CI du projet. Il ne s’agit toutefois pas d’un moyen de contrôle des logiciels malveillants. Les vagues de Mini Shai-Hulud de 2026 ont diffusé des paquets malveillants dotés d’une provenance valide, car le pipeline qui les avait générés avait bel et bien été compromis.

Que faut-il changer avant la prochaine édition ?

Aucune de ces options ne nécessite une refonte de la plateforme. Faites votre choix en fonction de l'état actuel de votre pipeline.

Si vos fichiers de verrouillage ne sont pas validés de manière cohérente, corrigez d'abord ce problème, puis basculez l'environnement de CI vers npm ci. C'est l'une des mesures de contrôle les plus simples de la liste, et elle aurait permis d'éviter purement et simplement cet incident particulier.

Si vous exécutez déjà npm ci partout, ajoutez une période de quarantaine pour les nouvelles versions. npm a intégré une fonctionnalité native min-release-age depuis la version 11.10.0 ; pnpm 11 active minimumReleaseAge activé par défaut à un jour, bien que cela n’empêche pas l’installation à moins que vous ne définissiez vous-même la valeur, et Unit 42 recommande de retarder toute publication effectuée au cours des 24 à 72 dernières heures , au motif que la plupart des paquets malveillants sont identifiés et supprimés au cours de cette période. Cela n’aurait pas permis de tout détecter, puisque le nettoyage complet du ver Shai-Hulud original avait pris plusieurs jours, mais cela couvre les cas les plus courants.

Si vous publiez vous-même des paquets, activez la fonctionnalité de provenance et passez à la publication sécurisée via OIDC plutôt qu’à l’utilisation de jetons de publication à longue durée de vie. L’attaquant d’axios a contourné le processus normal de publication OIDC du projet en utilisant un jeton classique volé, ce qui constitue un argument de poids en faveur de la suppression totale de ces jetons. Que vous en ayez conscience ou non, vous faites partie de la chaîne d’approvisionnement de quelqu’un d’autre.

Et si vos agents de compilation disposent d'identifiants de rôle dans le cloud, réduisez en priorité leur durée de validité. C'est ce qui fait la différence entre une mauvaise installation et un rapport d'incident.

Le problème, c’est que bon nombre des mesures préventives les plus efficaces interviennent avant ou au moment de la résolution des problèmes, alors que la plupart des efforts déjà déployés par les équipes visent à détecter les problèmes a posteriori. Ce n’est pas une critique à l’encontre de l’analyse de la composition logicielle, qui remplit parfaitement la fonction pour laquelle elle a été conçue. Il s’agit d’un problème de timing, et les problèmes de timing ne se résolvent pas en ajoutant simplement une analyse supplémentaire.

Votre expérience variera en fonction de la rapidité avec laquelle l'organisation a réellement besoin de nouvelles versions des dépendances. Les équipes qui déploient des outils d'IA s'appuyant sur des paquets en amont dont l'évolution est rapide paient le prix fort pour les fenêtres de quarantaine. Les équipes travaillant sur des plateformes internes dont l'évolution est plus lente en paient un prix bien moindre, et se rendent souvent compte qu'elles avaient déjà trois semaines de retard sur les versions mineures sans que personne ne s'en soit aperçu.

Le prochain est déjà en ligne quelque part

Trois heures, ça ne semble pas très long, jusqu’à ce qu’on compte le nombre d’installations qui ont eu lieu pendant ce laps de temps. C’est là la véritable leçon à retenir, et non pas l’attribution à la Corée du Nord ni la qualification de « ver ». C’est l’écart entre la publication et la détection, et le fait que, par défaut, il ne se passe pratiquement rien pendant ce laps de temps.

Axios a attiré l'attention. Les failles de sécurité de moindre importance ont tendance à passer beaucoup plus inaperçues. Elles sont retirées du registre sans faire de vagues, et ceux qui les ont déjà installées doivent évaluer eux-mêmes leur niveau d'exposition. La prochaine, nichée à quatre niveaux de profondeur dans l'arborescence des dépendances de quelqu'un, ne se fera pas non plus remarquer.

L'analyse basée sur les avis de sécurité est particulièrement efficace lorsque la menace est déjà connue. Pour détecter une attaque de la chaîne d'approvisionnement npm alors qu'elle est encore en cours, il faut effectuer un filtrage au moment de l'installation, plutôt que d'attendre que les avis de sécurité identifient d'abord le paquet concerné. C'est là que réside la lacune que SecureChain pour npm a été conçu pour combler.

FAQ

Qu'est-ce qu'une attaque de la chaîne d'approvisionnement npm ?

Une attaque de la chaîne d'approvisionnement npm consiste en la compromission d'un paquet dans le registre avant même qu'il ne vous parvienne, généralement par le biais d'identifiants de publication volés, d'un compte de responsable piraté ou d'une usurpation d'espace de noms, plutôt que par une faille dans votre propre code.

Que s'est-il passé avec la faille de sécurité d'Axios ?

Deux versions malveillantes d'axios, les versions 1.14.1 et 0.30.4, ont été mises en ligne le 31 mars 2026, puis retirées environ trois heures plus tard. Toutes deux injectaient une dépendance appelée plain-crypto-js qui déploiait un cheval de Troie d’accès à distance multiplateforme à partir d’un hook post-installation. Le Threat Intelligence Group de Google a attribué cette compromission au groupe UNC1069, tandis que Microsoft suit les activités qui s’y rapportent sous le nom de Sapphire Sleet. Les versions saines vers lesquelles se rabattre sont les versions 1.14.0 et 0.30.3.

L'outil npm audit détecte-t-il les paquets malveillants ?

Ses vérifications de vulnérabilité s’appuient sur les données d’alerte provenant du registre ; elles ne peuvent donc pas vous avertir d’une version récemment compromise tant que celle-ci n’a pas été identifiée et enregistrée. Dans le cas d’axios, une alerte a été émise dans le délai de trois heures, mais elle n’a pas pu annuler les installations déjà effectuées. Les signatures d'audit npm constitue une vérification distincte et plus utile dans ce contexte, car elle vérifie les signatures du registre et les attestations de provenance.

Un fichier de verrouillage offre-t-il une protection contre le détournement d'une version npm ?

Un fichier de verrouillage validé empêche la résolution d'une version inattendue, et npm ci est la méthode la plus stricte pour effectuer une installation à partir de ce fichier, car elle refuse de poursuivre l'opération lorsque le fichier de verrouillage et le fichier package.json ne correspondent pas. Cette protection disparaît lorsque le fichier de verrouillage est régénéré ou mis à jour vers une version incluant le compromis, et npm install est moins strict, car il peut modifier la résolution et réécrire le fichier de verrouillage.

Qu'est-ce que le ver Shai-Hulud ?

Il s'agit d'une campagne de logiciels malveillants npm à propagation autonome qui extrait des informations confidentielles des environnements infectés, identifie les jetons de publication npm et les utilise pour s'introduire dans d'autres paquets, élargissant ainsi le nombre de systèmes affectés sans que l'attaquant n'ait à intervenir davantage. Son code source ayant été rendu public en mai 2026, on assiste désormais à l'apparition de vagues de copies.

Comment puis-je vérifier si un paquet a été compilé par ses véritables responsables ?

Exécuter npm audit signatures pour vérifier les signatures du registre et, le cas échéant, les attestations de provenance. La provenance permet de confirmer qu’un artefact a bien été produit par la source et le workflow d’intégration continue (CI) qu’il prétend provenir, ce qui est une question distincte de celle de la sécurité du code, car un pipeline compromis peut produire une version correctement attestée.

Empêcher les publications non autorisées avant qu'elles ne soient résolues

Se fier uniquement aux flux d’alertes peut signifier que l’on n’apprend l’existence d’une version malveillante qu’une fois qu’elle a déjà été intégrée à une version. SecureChain for npm analyse les paquets au moment de leur résolution et les recompile à partir d’une source vérifiée afin de bloquer les artefacts compromis ou non conformes aux politiques avant qu’ils n’atteignent ce stade. Découvrez SecureChain pour npmet abonnez-vous à la newsletter de TuxCare pour recevoir chaque semaine les dernières actualités concernant la chaîne d'approvisionnement open source.

Résumé

Nom de l'article

L'attaque par chaîne d'approvisionnement visant Axios sur npm et ce qu'elle a révélé

Description

Deux versions malveillantes d'Axios sont restées actives pendant 3 heures. Découvrez ce que cette attaque de la chaîne d'approvisionnement npm a révélé et quelles mesures permettent réellement de l'empêcher.

Auteur

Tim Walker

Nom de l'éditeur

de TuxCare

Logo de l'éditeur