- Que s'est-il passé lors de l'attaque contre Axios via npm ?
- Comment une simple ligne dans le fichier package.json est devenue le vecteur d'attaque
- Pourquoi la révision de code traditionnelle n'a pas permis de détecter l'attaque contre Axios
- Pourquoi le rayon d'action s'étend à tout ce que le colis touche
- Quelles mesures de sécurité auraient pu changer le cours des événements ?
- En savoir plus surSupply Chain Software
- Questions fréquemment posées
Le détournement de paquets npm est une attaque visant la chaîne d'approvisionnement logicielle qui exploite la confiance accordée à un paquet pour mener l'attaque. Les attaquants n'ont pas besoin de modifier le code du référentiel s'ils parviennent à prendre le contrôle du compte qui publie le paquet.
C'est ce qui fait des paquets npm de confiance une surface d'attaque particulièrement vulnérable. Lorsqu'un compte de responsable de maintenance est piraté, tous les projets qui installent le paquet concerné peuvent être exposés à des risques lors d'une simple mise à jour de dépendances. L'incident Axios de mars 2026 a montré comment un seul compte npm piraté pouvait mettre en danger plus de 100 millions de téléchargements hebdomadaires sans que le code source d'Axios ne subisse de modification visible.
Comprendre le fonctionnement du détournement de paquets npm aide les équipes de sécurité à mettre en place des contrôles qui ciblent le véritable chemin d'attaque, plutôt que de se limiter aux fichiers source que la plupart des équipes examinent.
Que s'est-il passé lors de l'attaque contre Axios via npm ?
L'attaque npm visant Axios consistait en une prise de contrôle du compte d'un responsable de maintenance, qui a transformé un paquet de confiance en un vecteur de diffusion de logiciels malveillants. L'attaquant a compromis le compte npm du responsable principal d'Axios, a remplacé l'adresse e-mail enregistrée par une adresse qu'il contrôlait et a empêché le responsable légitime d'accéder à son compte.
L'opération était planifiée et mûrement réfléchie. Un paquet leurre a été publié environ 18 heures avant l'activation de la charge malveillante, créant ainsi un historique de publication qui n'a pas immédiatement éveillé les soupçons. Puis, en l'espace d'environ 39 minutes, le pirate a publié deux versions malveillantes : axios 1.14.1 pour la branche de publication moderne et axios 0.30.4 pour la branche héritée.
Les deux versions ont été mises à disposition simultanément afin d'optimiser leur visibilité. Ce choix a accru le risque que les environnements actuels et hérités téléchargent un paquet corrompu via le processus de mise à jour standard.
Comment une simple ligne dans le fichier package.json est devenue le vecteur d'attaque
Une simple modification d'une dépendance dans le fichier package.json peut constituer à elle seule l'ensemble de la chaîne d'attaque dans le cadre d'une attaque de la chaîne d'approvisionnement npm. Dans le cas de l'incident Axios, il n'a pas été nécessaire de modifier les fichiers source d'Axios, car le comportement malveillant a été introduit par le biais d'une nouvelle dépendance.
Cette vulnérabilité s'exploitait via un hook post-installation npm. Dès qu'une station de travail de développeur, un pipeline CI/CD ou un système de compilation exécutait la commande « npm install », le paquet malveillant pouvait contacter un serveur contrôlé par un pirate, récupérer une charge utile spécifique au système d'exploitation et commencer son exécution.
Les charges utiles ont été conçues pour macOS, Windows et Linux. L'attaque était, par nature, multiplateforme. Une fois exécuté, le dropper a effacé toute trace de son passage et a remplacé le fichier package.json d'origine par une version falsifiée, rendant ainsi l'analyse forensic ultérieure beaucoup plus difficile.
Pourquoi la révision de code traditionnelle n'a pas permis de détecter l'attaque contre Axios
La révision de code traditionnelle est conçue pour inspecter les modifications apportées au code source au sein d'un référentiel, mais cette faille de sécurité ne se trouvait pas dans le code source d'Axios. L'attaque contre Axios ne reposait pas sur des modifications visibles du référentiel, car la logique malveillante se trouvait dans une dépendance distincte et non dans le code source d'Axios.
Cette différence est importante. Un réviseur qui examinerait la mise à jour du paquet ne verrait guère plus qu'une nouvelle ligne de dépendance dans le fichier package.json. Le comportement malveillant ne se manifestait qu'une fois la dépendance résolue et installée.
C'est pourquoi les attaques par paquets de confiance sont difficiles à détecter en se basant uniquement sur une analyse par comparaison. Le chemin d'attaque se situe en dehors des fichiers source que la plupart des équipes examinent, même si le paquet semble suffisamment légitime pour passer à travers les processus de développement habituels.
Pourquoi le rayon d'action s'étend à tout ce que le colis touche
La portée d'impact d'un paquet npm compromis ne se limite pas au paquet lui-même. Elle englobe tout ce avec quoi ce paquet entre en contact.
Pour la plupart des organisations, cela inclut les pipelines CI/CD dotés de droits d'accès élevés, les points de terminaison des développeurs avec des clés SSH et des jetons cloud, les serveurs de compilation disposant d'un accès en écriture aux référentiels d'artefacts, ainsi que les outils de déploiement connectés aux systèmes de production. Un paquet malveillant n'a pas besoin de rester dans l'arborescence des dépendances pour causer des dommages. Il lui suffit d'un seul point d'exécution de confiance.
C'est pourquoi l'incident Axios revêt une importance qui dépasse le simple cadre de la gestion des paquets JavaScript. Une compromission survenant après l'installation peut transformer une opération d'installation normale en vol d'identifiants, en déplacement latéral ou en accès à l'infrastructure en aval.
Les faiblesses structurelles mises en évidence par l'attaque d'Axios
L'incident d'Axios a mis en évidence des faiblesses structurelles courantes dans les environnements modernes de développement logiciel. Il ne s'agit pas là de cas marginaux et rares, mais d'hypothèses courantes dans de nombreuses organisations.
Confiance dans l'identité des responsables de paquets
La confiance accordée à un paquet npm est souvent liée au compte du responsable qui publie le paquet. Si ce compte est piraté ou victime d'une attaque par hameçonnage, l'attaquant hérite des mêmes droits de publication que le responsable légitime.
Versions flottantes des dépendances
Les versions flottantes ou faiblement verrouillées augmentent le risque d'exposition à des versions malveillantes. Une version compromise récemment publiée peut s'introduire automatiquement dans un environnement sans passer par une étape d'approbation délibérée.
Scripts post-installation non surveillés
Les scripts post-installation npm peuvent exécuter du code arbitraire avec les droits du processus d'installation. De nombreuses organisations ne vérifient ni ne restreignent les scripts de cycle de vie avant leur exécution.
Pipelines CI/CD avec une visibilité limitée sur l'exécution
Les pipelines CI/CD disposent souvent d'un accès étendu aux systèmes internes, à l'infrastructure de compilation et aux environnements cloud. Ces pipelines sont généralement considérés comme fiables par défaut et font rarement l'objet d'une surveillance visant à détecter tout comportement malveillant des paquets lors de leur installation.
Points de terminaison des développeurs hors de la couverture de sécurité complète
Les machines des développeurs hébergent des ressources de grande valeur, notamment des clés SSH, des identifiants de connexion au cloud et des jetons d'entreprise. Les terminaux des développeurs constituent également des cibles d'attaque courantes, car ils peuvent bénéficier d'une visibilité moindre et de contrôles d'exécution moins stricts que les systèmes de production.
Magasins d'informations d'identification sans déclencheurs de rotation rapide
Une attaque visant la chaîne logistique logicielle se traduit souvent par une fuite d'identifiants. De nombreuses équipes ne disposent toujours pas de processus fiables permettant d'identifier les informations confidentielles potentiellement exposées et de les renouveler immédiatement.
Quelles mesures de sécurité auraient pu changer le cours des événements ?
Trois catégories de contrôles de sécurité auraient permis de réduire considérablement l'impact de l'attaque contre Axios. Chaque contrôle porte sur un maillon différent de la chaîne d'attaque : l'exécution des paquets, la divulgation des identifiants et la visibilité des dépendances.
1. Analyse antivirus au niveau du paquet avant l'installation
L'analyse des logiciels malveillants au niveau des paquets permet de bloquer les dépendances malveillantes avant leur exécution. Cela revêt une importance particulière dans le cas des attaques via npm, car les hooks post-installation s'exécutent pendant l'installation, ce qui laisse peu de temps pour une vérification manuelle une fois le paquet téléchargé.
L'analyse des paquets, des dépendances et des scripts de cycle de vie avant l'installation permet de détecter les logiciels malveillants connus, les comportements suspects, les vulnérabilités et les secrets codés en dur avant que le paquet n'atteigne le terminal d'un développeur ou un environnement CI/CD.
MetaDefender Software Supply Chain est la solution de sécurité de la chaîne logistique logicielle OPSWATdestinée à valider les composants logiciels, les fournisseurs et les pipelines de compilation. Elle utilise une détection des menaces multi-moteurs, notamment le scan multiple Metascan sur plus de 30 moteurs antivirus, pour inspecter les paquets à la recherche de logiciels malveillants, de vulnérabilités et de secrets codés en dur avant qu'ils n'entrent dans le cycle de développement.
2. Gestion proactive des secrets grâce à des déclencheurs de rotation
Une gestion proactive des secrets réduit l'impact d'une intrusion réussie. Lorsqu'un paquet suspect est identifié, les équipes doivent disposer d'un plan d'action qui considère les identifiants locaux, les clés SSH, les jetons et les secrets de pipeline comme potentiellement compromis, et qui procède à leur rotation rapide.
La détection des secrets codés en dur va dans le même sens. Un paquet malveillant peut voler des secrets en mémoire ou sur le disque, mais les secrets exposés déjà présents dans le code ou les dépendances constituent un risque supplémentaire qui peut être évité.
3. Supply Chain et suivi des dépendances
La visibilité sur la chaîne logistique permet aux équipes de détecter les modifications inattendues apportées aux paquets avant que celles-ci ne se traduisent par des incidents en aval. Les équipes de sécurité doivent savoir quels paquets sont installés, quelles versions sont verrouillées, quelles nouvelles dépendances sont apparues et où ces composants sont exécutés.
Sans visibilité ni surveillance des dépendances, le premier signe d'une intrusion peut se traduire par une utilisation abusive des identifiants ou une exploitation malveillante de l'infrastructure, bien après que l'installation initiale ait eu lieu.
En savoir plus surSupply Chain Software
La sécurité de la chaîne Software repose sur l'analyse des paquets avant leur exécution, la surveillance des nouvelles dépendances et la réduction de l'exposition des identifiants qui résulte de la compromission d'un paquet.
Regardez le webinaire à la demande :Supply Chain Software — Les maillons faibles exploités par les pirates
Questions fréquemment posées
Qu'est-ce qu'une attaque de la chaîne d'approvisionnement npm ?
Une attaque de la chaîne d'approvisionnement npm consiste à introduire du code malveillant via l'écosystème npm dans le cadre d'activités normales de développement logiciel. Les attaquants y parviennent généralement en compromettant le compte d'un responsable de maintenance, en publiant un paquet trompeur ou en intégrant un comportement malveillant dans des dépendances que les développeurs et les systèmes CI/CD installent automatiquement.
Comment les pirates ont-ils réussi à compromettre le paquet npm d'Axios ?
Des pirates ont compromis le compte npm du responsable principal d'Axios et ont utilisé ce droit de publication pour diffuser des versions malveillantes sur les branches de version 1.x et 0.x. Ils ont également remplacé l'adresse e-mail associée au compte par une adresse qu'ils contrôlaient, ce qui leur a permis de garder le contrôle du paquet.
Quelles ont été les actions du logiciel malveillant utilisé lors de l'attaque contre Axios ?
Le logiciel malveillant utilisé lors de l'attaque contre Axios exploitait un hook post-installation pour s'exécuter pendant l'opération « npm install ». Ce hook contactait un serveur contrôlé par le pirate, téléchargeait un cheval de Troie d'accès à distance pour macOS, Windows ou Linux, le lançait, puis tentait d'effacer toute trace en remplaçant les métadonnées du paquet par du contenu falsifié.
Pourquoi la révision du code n'a-t-elle pas permis de détecter l'attaque visant la chaîne d'approvisionnement d'Axios ?
La révision du code n'a pas permis de détecter l'attaque visant Axios, car le code malveillant n'avait pas été introduit dans le code source d'Axios. La seule modification visible au niveau du dépôt était l'ajout d'une dépendance dans le fichier package.json, tandis que le logiciel malveillant proprement dit a été introduit via un paquet externe, hors du champ d'application habituel de la révision du code source.
Comment les organisations peuvent-elles détecter les paquets npm malveillants avant leur installation ?
Les entreprises peuvent détecter les paquets npm malveillants avant leur installation en analysant le contenu des paquets, les arborescences de dépendances et les scripts de cycle de vie avant leur exécution. Des contrôles efficaces associent l'analyse des logiciels malveillants, l'analyse des dépendances, l'application des politiques et l'intégration CI/CD, afin que les paquets suspects puissent être bloqués avant d'atteindre les environnements de développement ou de compilation.
Le verrouillage des versions permet-il d'empêcher les attaques visant la chaîne d'approvisionnement npm ?
Le verrouillage de version réduit l'exposition aux versions malveillantes récemment publiées, car il limite les mises à jour automatiques. Le verrouillage de version n'élimine pas les risques liés à la chaîne d'approvisionnement, car une version verrouillée peut déjà avoir été compromise ou d'autres failles de confiance peuvent encore exister. Le verrouillage de version est particulièrement efficace lorsqu'il est associé à une vérification de l'intégrité, à une inspection des paquets et à des contrôles d'exécution.
