Compromission du package npm Axios : ce qui s'est passé, ce qui compte et comment réagir

Que s'est-il passé lors de l'incident de compromission du paquet npm d'Axios ?

L'affaire de la compromission du paquet npm « Axios » nous rappelle que les risques liés aux logiciels modernes ne se présentent pas toujours sous la forme d'un CVE classique ou d'une faille divulguée dans le code source. Parfois, le véritable problème réside dans une version de paquet compromise, une chaîne de dépendances corrompue et un chemin d'exécution lors de l'installation qui transforme une mise à jour de routine en incident de sécurité.

Pour les équipes chargées de la sécurité et de l'informatique, la question urgente ne se résume pas à « Axios a-t-il été touché ? » mais « Où se trouvent exactement les versions concernées, ce qui a déjà été exécuté, et ce qui doit être recompilé ou examiné dès maintenant ? »

Selon un rapport récent du secteur , disponible à l'adresse , des pirates auraient publié des versions malveillantes du paquet Axios sur npm après avoir compromis le compte d'un responsable de maintenance. Les versions malveillantes auraient affecté à la fois la version principale et l'ancienne version  , et auraient introduit une dépendance dont le but principal était de déclencher l'exécution au moment de l'installation.

[Administrateurs Linux : voici ce que vous devez savoir sur « Copy Fail », la faille de sécurité du noyau permettant l'escalade des privilèges et offrant aux utilisateurs non privilégiés un moyen concret d'accéder au compte root]

Le point important soulevé par l'  est le suivant : Axios n'a pas été « exploité » au sens classique du terme, c'est-à-dire par le biais d'un bug logiciel pouvant être déclenché à distance. Au contraire, le risque provenait de la chaîne d'approvisionnement logicielle de l' .

Pourquoi cet incident est-il important ?

Axios est l'un des clients HTTP JavaScript les plus utilisés au sein d'un écosystème où plus de 454 600 nouveaux paquets malveillants ont été identifiés dans les principaux registres open source en 2025 , selon Sonatype.
Axios est utilisé dans :

• Postes de travail pour développeurs
• Exécuteurs CI/CD
• Serveurs de compilation
• Charges de travail éphémères dans le cloud
• Systèmes de production qui installent les dépendances de manière dynamique

Lorsqu'un paquet largement utilisé est compromis, l'ampleur des répercussions dépend moins de la popularité du paquet en soi que du nombre d'environnements ayant effectivement résolu et installé les versions concernées pendant la période d'exposition.

Le nombre de téléchargements hebdomadaires a fait d'Axios l'une des bibliothèques clientes HTTP JavaScript les plus utilisées de l'écosystème npm, ce qui signifie que même une brève période d'exposition lors de l'attaque de la chaîne d'approvisionnement « mars 2026 » a eu un impact potentiel considérable.

[Lisez notre analyse de l'incident de sécurité chez Vercel pour comprendre comment la relation de confiance OAuth a été détournée, pourquoi il s'est avéré difficile de déterminer l'étendue de l'incident, et ce que cette faille révèle sur les attaques modernes axées sur l'identité]

Versions malveillantes signalées

D'après les informations rendues publiques, les versions les plus fréquemment identifiées comme malveillantes étaient les suivantes :

Une analyse publique a également établi un lien entre ce compromis et une dépendance inattendue utilisée pour déclencher un comportement après l'installation.

Si votre environnement contient ces versions de paquets ou la dépendance inattendue mentionnée ci-dessus, cela peut constituer un signe fort vous invitant à approfondir votre analyse.

Une analyse indépendante de rétro-ingénierie et des menaces, disponible à l'adresse , montre que des paquets dépendants de l'écosystème npm utilisaient Axios au moment de la compromission de la chaîne d'approvisionnement d'mars 2026 , ce qui illustre l'ampleur potentielle des répercussions de la publication de ce paquet malveillant.

Pourquoi la compromission du paquet npm d'Axios diffère d'une vulnérabilité classique

La plupart des programmes de gestion des vulnérabilités s'articulent autour des failles connues, des plages de versions concernées et des recommandations relatives aux correctifs. Cet événement s'écarte de ce modèle à plusieurs égards importants.

Il s'agissait d'un problème lié à la gestion des paquets, et non pas simplement d'un défaut de code

Le risque provenait d'un événement de publication malveillant. Cela signifie que :

• Il se peut qu'il n'y ait pas de CVE permettant d'ancrer la réponse
• Les métadonnées d'un paquet sont tout aussi importantes que le code source
• Le comportement de résolution des dépendances vient s'ajouter à la surface d'attaque
• Les scripts d'installation et les hooks post-installation constituent des éléments de preuve essentiels

Elle visait le chemin de dépendance

De nombreuses équipes continuent de se concentrer sur les dépendances directes dans le fichier `package.json` de . Cependant, étant donné que de nombreuses attaques visant la chaîne d'approvisionnement trouvent leur origine dans des dépendances compromises, des incidents comme celui-ci montrent pourquoi les dépendances transitives et fantômes revêtent une importance particulière.

C'est pourquoi l'examen traditionnel des applications ne suffit pas à lui seul.

Il est compatible avec différents systèmes d'exploitation

Des recherches publiques indiquent que la chaîne d'installation a entraîné des comportements spécifiques à chaque plateforme sous Windows, macOS et Linux. C'est important, car la réponse ne peut pas se limiter au « risque lié aux ordinateurs portables des développeurs » ou au « risque lié aux agents de compilation Linux ». Les équipes ont besoin d'une visibilité multiplateforme.

Ce que les équipes de sécurité devraient faire en priorité

Lors d'incidents liés à la chaîne d'approvisionnement, les équipes se laissent souvent aller à des conjectures avant d'avoir vérifié ce qui se passe réellement. Avant de vous concentrer sur les indicateurs, commencez par vous poser la question la plus simple :

Disposez-vous des versions des paquets concernés quelque part dans l'environnement ?

Cet ordre a son importance.

Commencez par la présence, passez ensuite au comportement, puis évaluez l'impact

Voici à quoi peut ressembler un modèle de réponse concret :

Cette approche permet de limiter le bruit et aide les équipes à ne pas réagir de manière excessive aux gros titres, tout en continuant à agir rapidement face à une exposition réelle.

Ce qu'il faut rechercher dans votre environnement

Si vous évaluez l'exposition potentielle liée à la compromission du paquet npm « Axios », examinez l'ensemble des terminaux, des serveurs et des systèmes CI/CD afin de repérer toute combinaison de traces du paquet, de comportements des processus, d'artefacts de fichiers et d'activité réseau.

Données au niveau de l'emballage

Vérifiez les points suivants :

• Axios version 1,14,1
• Axios version 0,30,4
• plain-crypto-js version 4,2,1
• Les modifications apportées au fichier de verrouillage ont entraîné une résolution inattendue des dépendances
• Installation du paquet pendant la période d'exposition connue

Données relatives aux terminaux et aux charges de travail

En fonction de la plateforme, les enquêteurs doivent rechercher des indices indiquant l'exécution de scripts lors de l'installation, le téléchargement progressif de charges utiles ou la création de processus enfants suspects à partir de Node.js ou de npm.

Voici quelques catégories utiles :

• Exécution d'un script ou d'un programme shell lancée par npm ou Node.js
• Activité inattendue de PowerShell, Python, curl ou du shell après l'installation d'un paquet
• Le fichier écrit dans des répertoires temporaires
• Fichiers binaires renommés ou dissimulés
• Processus d'arrière-plan détachés
• Trafic sortant inhabituel provenant des systèmes de développement ou de compilation

Preuves relatives au CI/CD

Les pipelines de compilation méritent une attention particulière, car ils présentent souvent les caractéristiques suivantes :

• Accès étendu au réseau
• Secrets injectés
• Identifiants de connexion au cloud
• Jetons de déploiement
• Résolution automatisée des paquets

Si un exécuteur CI a installé ces versions malveillantes du paquet, ne considérez pas cet incident comme une simple alerte liée aux dépendances de développement. Critique :

• Journaux des flux de travail
• Calendrier de résolution des dépendances
• Connexions réseau sortantes
• Les secrets liés à ce poste
• Intégrité des artefacts pour les versions générées au cours de cette période

Mesures correctives immédiates

Si vous constatez la présence des versions concernées, agissez rapidement mais de manière méthodique.

Les mesures ci-dessous correspondent aux mesures de confinement couramment mises en œuvre lors d'incidents affectant la chaîne d'approvisionnement, tels que la compromission du paquet npm d'Axios. Elles ne sont pas destinées à être mises en œuvre dans un ordre précis, et les organisations doivent les appliquer en fonction de la criticité du système, des exigences en matière d'autorisation et de la tolérance au risque.

Liste de contrôle relative au confinement

Modifications apportées aux mesures d'hygiène des emballages en toute sécurité

Même une fois l'incident immédiat résolu, les équipes doivent renforcer les contrôles relatifs aux colis :

• Privilégiez le verrouillage de version exact pour les dépendances critiques
• Vérifier les fichiers de verrouillage lors de la révision du code
• Limitez autant que possible l'utilisation des scripts d'installation dans l'environnement de CI
• Séparer les secrets de compilation de la résolution courante des dépendances
• Imposer des contrôles de provenance lors de la publication et de l'utilisation des paquets
• Surveiller les paquets présents dans les manifestes mais absents de l'utilisation réelle de l'application

Comment Tanium peut vous aider à faire face à l'incident survenu au sein de la chaîne d'approvisionnement d'Axios

Le tableau de bord « Axios Supply Chain Compromise » d’ , Tanium Guardian et , aide les équipes de sécurité et informatiques à déterminer rapidement si des paquets Axios compromis sont présents dans leur environnement et, le cas échéant, à évaluer l’impact potentiel.

Le tableau de bord se concentre tout d'abord sur l'évaluation de l'exposition, permettant ainsi aux équipes de suivre les versions compromises d'Axios (v1,14,1 et v0,30,4 , anciennes versions) à l'aide des données de la liste des composants logiciels (SBOM) de Tanium, disponibles à l'adresse , afin de déterminer si les paquets concernés ont été intégrés à un endroit quelconque de leur environnement. Cela permet aux équipes de sécurité et informatiques d'aller au-delà des conjectures et de répondre à la question la plus urgente en cas d'incident touchant la chaîne d'approvisionnement : savoir si le logiciel compromis est effectivement présent.

Pour les organisations disposant de capacités d'investigation avancées, le tableau de bord prend en charge les investigations multiplateformes « Stage 2 » sur macOS, Windows et Linux afin de faciliter l'identification des artefacts RAT et des activités potentielles de commande et de contrôle associées à la dépendance malveillante.

Lorsque la solution « Tanium Threat Response » ( ) est disponible, les équipes peuvent également mettre en œuvre des mesures d'intervention, telles que la mise en quarantaine des terminaux affectés.

Le fonctionnement complet du tableau de bord dépend de la mise en place de Tanium SBOM et de Tanium Threat Response, ainsi que de l'attribution de rôles appropriés en matière de création de rapports et d'accès aux informations, ce qui reflète l'approche modulaire de Tanium en matière de validation des vulnérabilités, d'investigation et de réponse.

Pourquoi les données SBOM modifient le débat sur la réponse

Une nomenclature logicielle ( ) est parfois considérée comme un simple document de conformité, alors même que la CISA, la NSA et 19 partenaires internationaux ont déclaré que son adoption constituait une étape incontournable en matière de sécurité. Des incidents comme celui-ci montrent pourquoi cette vision est trop restrictive.

En cas de compromission d'un paquet, les données SBOM peuvent permettre de déterminer quels artefacts compilés contenaient le paquet concerné, quelles versions étaient incluses et si des dépendances suspectes associées avaient été déclarées. Pour déterminer où ces artefacts ont été déployés ou quels systèmes ont installé ces paquets, il est nécessaire de disposer de données télémétriques supplémentaires sur les terminaux, les conteneurs et les pipelines.

En l'absence de cette visibilité, les équipes ont tendance à se fonder sur des indicateurs approximatifs :

• Recherches dans les référentiels
• Déclaration volontaire des développeurs
• Indices EDR incomplets
• Vérification manuelle des fichiers de verrouillage
• Hypothèses concernant ce qui « devrait » être installé

Ces informations sont utiles, mais elles ne sauraient se substituer aux données issues de l'environnement.

SBOM ou triage fondé sur des hypothèses

Le triage basé sur la SBOM s'appuie sur ce qui est réellement présent sur les terminaux, et non sur des déductions tirées uniquement des référentiels ou des alertes.

L'analyse de StepSecurity, disponible à l'adresse , montre que cette faille reposait sur l'injection d'une dépendance inattendue (plain-crypto-js), et non sur une modification du code source d'Axios — ce qui illustre pourquoi une visibilité au niveau des composants, telle que celle offerte par le SBOM, est essentielle dans les incidents liés à la chaîne d'approvisionnement.

Erreurs courantes à éviter

Les équipes chargées de remédier à la faille de sécurité du paquet npm « Axios » doivent se méfier de quelques pièges prévisibles. Les exemples ci-dessous illustrent des schémas courants observés lors d'incidents touchant la chaîne d'approvisionnement tels que celui-ci, mais les décisions concrètes en matière d'intervention doivent être guidées par l'architecture, la tolérance au risque et l'environnement opérationnel propres à chaque organisation.

Considérer cela comme « un simple problème de développement »

Si un paquet compromis était exécuté dans l'environnement de CI, le risque pourrait s'étendre au-delà des postes de travail individuels des développeurs pour concerner les identifiants, les artefacts de compilation et les environnements en aval. Dans de nombreuses organisations, les systèmes de CI disposent d'un accès plus étendu et de privilèges plus élevés que les terminaux des développeurs.

Recherche uniquement les utilisations directes d'Axios

L'exposition pourrait ne pas se limiter aux applications qui déclarent explicitement Axios comme dépendance directe. Le paquet peut apparaître dans des chemins de dépendances transitifs, des contextes de compilation éphémères ou des environnements de courte durée, qui sont faciles à négliger lors du triage initial.

L'absence de CVE implique un niveau d'urgence faible

Les failles de la chaîne d'approvisionnement peuvent entraîner un risque opérationnel réel sans pour autant s'inscrire clairement dans les processus traditionnels de gestion des vulnérabilités de l' . Les équipes habituées à établir leurs priorités en fonction des CVE peuvent sous-estimer les incidents liés à la fiabilité des paquets qui ne correspondent pas à un identifiant de vulnérabilité connu.

Nettoyage en place après validation de l'exécution

Si un comportement malveillant est confirmé, en particulier dans des environnements privilégiés ou contenant de nombreuses informations confidentielles, il est souvent plus sûr de procéder à une restauration à partir d’un état connu pour être sain que de tenter un nettoyage sur place. La réponse appropriée dépendra du rôle au sein du système, du niveau de privilèges et de l'exposition à des identifiants sensibles.

Exemple de processus d'enquête

La séquence ci-dessous illustre une manière possible dont les équipes de sécurité et informatiques pourraient organiser une enquête sur un incident tel que la compromission du paquet npm d'Axios. Ce document est fourni à titre d'exemple et non comme une liste de contrôle contraignante ; il doit être adapté en fonction des outils, de l'environnement et du profil de risque de l'organisation.

Phase 1 : Vérification de l'exposition

• Systèmes de gestion des stocks utilisant les versions concernées d'Axios
• Identifier la présence de dépendances suspectes ou inattendues
• Indiquez où l'installation du paquet a eu lieu pendant la période d'exposition

Phase 2 : Analyser l'exécution

• Examiner les processus enfants de npm et de Node.js
• Vérifier la création de fichiers temporaires et le lancement de commandes shell
• Recherchez les interpréteurs de scripts suspects et les processus isolés
• Mettre en corrélation les connexions réseau sortantes des hôtes concernés

Phase 3 : Évaluation des répercussions en aval

• Déterminez si des identifiants ou des secrets étaient accessibles
• Examinez les modifications apportées aux artefacts de compilation générés pendant la période d'exposition
• Évaluer les indicateurs de persistance ou de diffusion d'une charge utile secondaire
• Choisissez entre le nettoyage et la reconstruction en fonction de votre niveau de confiance et des risques encourus

Phase 4 : Renforcement

• Fixer les dépendances à des versions dont la sécurité est avérée
• Limitez autant que possible l'exposition des scripts d'installation
• Améliorer la couverture des dépendances et de la SBOM
• Renforcer la gestion des secrets de CI
• Examiner les contrôles relatifs à la fiabilité et à la provenance des éditeurs

Pour les organisations qui mettent en place ce type de réponse, des pratiques plus larges en matière de conformité ( , gestion des vulnérabilités et , conformité ) peuvent contribuer à coordonner l'identification, la hiérarchisation et la correction des vulnérabilités sur l'ensemble des actifs concernés, tout en conservant une certaine souplesse en fonction des risques spécifiques à chaque environnement.

Foire aux questions concernant l'incident chez Axios

Axios était-il lui-même vulnérable ?

Pas au sens habituel du terme, c'est-à-dire une faille logicielle comportant une voie d'exploitation et un correctif. Le problème était lié à une faille dans la chaîne logistique impliquant la publication de paquets malveillants.

Quelles versions d'Axios ont été signalées comme étant concernées ?

Les informations rendues publiques ont systématiquement désigné « axios 1,14,1 » et « axios 0,30,4 » comme les versions npm malveillantes liées à cet incident.

Pourquoi la faille de sécurité du paquet npm « Axios » est-elle importante, alors qu'elle n'a duré que peu de temps ?

En effet, même des compromissions de paquets de courte durée peuvent encore affecter des systèmes de grande valeur si, pendant la période d'exposition, la version compromise est récupérée et installée. La désinstallation rapide n'annule pas les installations déjà effectuées.

Les organisations devraient-elles procéder à une rotation des identifiants ?

Si les paquets concernés ont été installés sur des systèmes ayant accès à des secrets, des jetons, des identifiants de connexion au cloud ou des clés de déploiement, la vérification et la rotation des identifiants doivent faire partie des mesures à prendre.

Est-ce que la vérification des dépôts de sources suffit ?

Non. L'analyse Repo est utile, mais elle ne permet pas de déterminer ce qui a réellement été installé sur les terminaux, les agents de compilation et les charges de travail. La visibilité au niveau de l'environnement est essentielle, et des outils tels que Tanium peuvent fournir des données de télémétrie sur les fichiers et les processus des terminaux, mais la présence des paquets doit souvent être confirmée à l'aide de données supplémentaires issues des artefacts, des référentiels et des pipelines.

La principale leçon à tirer de la compromission du paquet npm d'Axios

Une stratégie de réponse aux incidents bien rodée ne repose pas uniquement sur les flux d'informations sur les vulnérabilités. Cela nécessite de savoir répondre rapidement à trois questions concrètes :

1. Où se trouve exactement le paquet concerné ?
2. Quel problème avez-vous constaté après l'installation ?
3. Quelles en ont été les répercussions opérationnelles ?

Pour les équipes de sécurité, c'est là toute la différence entre réagir aux gros titres et réagir aux faits. Des enseignements similaires ont été tirés d’incidents récents liés à la chaîne d’approvisionnement , tels que XZ Utils et 3CX, , dans lesquels l’accès de développeurs de confiance ou l’infrastructure de compilation a été détourné pour introduire des portes dérobées — ce qui souligne encore davantage pourquoi les équipes doivent éviter d’évaluer les risques logiciels de manière trop restrictive, en se basant uniquement sur les CVE.

Ressources complémentaires

• Tableau de bord « Tanium Guardian Axios » consacré aux atteintes à la chaîne d'approvisionnement
• Site web d'Axios
• Analyse de la compromission d'Axios par la base de données des menaces de la communauté OpenSourceMalware
• Analyse technique d'Elastic Security

Si votre équipe est en train de repenser la manière dont elle évalue l’exposition aux dépendances sur les terminaux, les serveurs et les environnements de compilation où les logiciels sont effectivement installés et exécutés, Tanium aide les équipes à partir d’une analyse concrète de la situation sur le terrain, à étudier les comportements de manière rigoureuse et à réagir en s’appuyant sur des informations vérifiées et en temps réel concernant les terminaux. Prenez rendez-vous pour une démonstration gratuite d' , adaptée à votre environnement.