Attaque sur Axios : RDAP multiplateforme via npm compromis

Partager
Attaque sur Axios : RDAP multiplateforme via npm compromis

Origines et historique

L'incident récent impliquant la bibliothèque Axios a rappelé, sans surprise pour ceux qui suivent la chaîne d'approvisionnement JavaScript, combien la compromission d'un compte mainteneur peut avoir des conséquences en cascade. En mars 2026, des versions 1.14.1 et 0.30.4 d'Axios ont été publiées depuis un compte compromis, et contenaient la dépendance frauduleuse plain-crypto-js en version 4.2.1, conçue pour servir de porte dérobée et déployer des charges malveillantes sur les machines des utilisateurs¹. Ce type d'attaque exploite la confiance implicite que les projets et outils accordent aux paquets publiés sur le registre npm.

Ce scénario n'est pas nouveau. En 2018, le paquet event-stream a été compromis au travers d'un contributeur tiers qui a introduit une dépendance malveillante destinée au vol de fonds Bitcoin, montrant qu'une simple mise à jour peut transformer une dépendance très utilisée en vecteur d'attaque². Plus près de nous, la compromission de Codecov en avril 2021 a démontré combien un outil de pipeline CI mal protégé peut exposer des tokens et des secrets à grande échelle³. Deux motifs reviennent systématiquement: la compromission d'identifiants ou de pipelines CI, et la publication de dépendances trojanisées qui profitent de la nature transitive des dépendances Node.js.

Fonctionnement technique

Vecteurs d'injection

  • Compromission d'identifiants ou de tokens npm: un attaquant publie une version malveillante en utilisant des accès légitimes. Dans l'incident Axios, les versions compromises ont été diffusées sous des numéros de version inattendus¹.
  • Publication d'une dépendance trojanisée: la dépendance plain-crypto-js@4.2.1 a été ajoutée au manifeste, puis utilisée pour exécuter des actions indésirables lors de l'installation ou à l'importation du module.

Ces deux vecteurs exploitent des habitudes de développement: confiance dans la mise à jour automatique, confiance dans les mirrors internes, et confi ance dans les artefacts fournis par des tiers.

Mécanismes d'exécution et persistance

Les paquets npm peuvent exécuter du code dès l'installation ou à l'importation, ce qui ouvre plusieurs mécanismes d'exécution pour un malware visant la plateforme Node.js:

  • Scripts postinstall dans package.json qui lancent des commandes arbitraires.
  • Code JavaScript exécutable dès que le module est requis.
  • Inclusion d'un binaire natif empaqueté et exécuté sur la machine cible.
  • Téléchargement dynamique d'un payload chiffré depuis un domaine contrôlé par l'attaquant.

Une fois l'exécution obtenue, les actions malveillantes typiques incluent l'inventaire des fichiers et variables d'environnement (à la recherche de tokens CI, clés cloud, ou clés privées locales), l'exfiltration de données via HTTPS ou canaux DNS, l'ouverture de shells à distance ou de tunnels inverses, et le pivot vers d'autres services si des secrets ont été trouvés.

Illustration cybersécurité

La dangerosité tient aussi à l'omniprésence d'Axios dans l'écosystème Node.js: utilisé directement ou via d'autres bibliothèques, un paquet compromis peut toucher des milliers de projets. Par ailleurs, les clients npm ne vérifient pas systématiquement des signatures cryptographiques sur les tarballs, laissant un vide exploitable pour des distributions malveillantes⁴.

Indicateurs techniques à rechercher

  • Présence de axios@1.14.1 ou axios@0.30.4 dans vos lockfiles (package-lock.json, yarn.lock).
  • plain-crypto-js@4.2.1 dans l'arbre des dépendances.
  • Scripts postinstall ou scripts suspects dans node_modules/plain-crypto-js/package.json.
  • Connexions réseau inattendues pendant l'installation (processus npm/node établissant des connexions sortantes).
  • Hashes de tarballs ou checksums différents de ceux publiés officiellement par le projet.

Pour une vérification rapide, recherchez axios@1.14.1 et axios@0.30.4 dans vos fichiers de lock, puis inspectez l'arborescence node_modules pour déceler plain-crypto-js. Si votre CI a des artefacts ou images construites aux dates de publication suspectes, inspectez-les pour identifier des exécutables ou scripts nouveaux.

Études de cas

event-stream (2018) - compromission via un mainteneur tiers

  • Faits: un nouvel auteur a introduit une dépendance malveillante dans event-stream, visant des portefeuilles Node.js. L'attaque a tiré parti de la confiance accordée à une mise à jour apparemment légitime².
  • Impact: vol de fonds pour certaines cibles et remise en question des processus de gouvernance de paquets populaires.
  • Leçon: toute modification impliquant un changement de mainteneur ou l'ajout d'une dépendance doit être revue avec des critères de sécurité stricts.

Codecov (avril 2021) - compromission du pipeline CI

  • Faits: une modification malveillante dans un outil de transfert CI a conduit à l'exfiltration massive de tokens et secrets d'environnements clients³.
  • Impact: rotation massive des clés et audits profonds nécessaires chez des milliers d'organisations.
  • Leçon: renforcer l'intégrité des outils utilisés dans les pipelines de build et limiter les privilèges de ces outils.

Incident Axios (mars 2026) - publication via un compte compromis

  • Faits: deux versions d'Axios publiées depuis un compte compromis intégraient un paquet falsifié, probablement pour déployer un RAT multi-plateforme¹. Le manifeste de la version 1.14.1 est répertorié publiquement sur npm⁴.
  • Impact potentiel: propagation dans de nombreux projets consommateurs d'Axios, risque d'exfiltration de secrets en environnements de développement et CI.

Mesures opérationnelles et recommandations

Les réponses immédiates et à moyen terme doivent combiner actions techniques et décisions organisationnelles:

  • Réaction immédiate: isoler les systèmes infectés, suspendre les pipelines utilisant les versions compromises, retirer ces versions des mirrors internes et bloquer leur installation. Procéder à la rotation des secrets potentiellement exposés (tokens CI, clés cloud) et lancer une enquête forensique sur les machines et les logs réseau.
  • Correction des dépendances: verrouiller les dépendances sur des versions saines, appliquer des versions publiées et signées si disponibles, ou utiliser des forks contrôlés et revus.
  • Durée de vie des credentials: limiter la portée et la durée des tokens utilisés par les intégrations CI, automatiser la révocation lorsqu'un comportement anormal est détecté.
  • Renforcement du pipeline: intégrer des scans SCA et générer un SBOM pour chaque build; bloquer automatiquement l'ajout de nouvelles dépendances non approuvées; vérifier les checksums et signatures des paquets critiques.
  • Pratiques mainteneur: activer l'authentification à deux facteurs pour tous les comptes ayant des droits de publication, limiter les personnes pouvant publier, auditer régulièrement les changements de mainteneurs et signer les releases.
  • Infrastructures de confiance: adopter des standards de chaîne de confiance tels que SLSA et Sigstore pour signer artefacts et garantir l'intégrité des publications.

Adopter ces mesures réduit fortement la probabilité d'une compromission réussie et limite l'impact lorsqu'un incident survient.

Perspectives et priorités

Les attaques ciblant la chaîne d'approvisionnement logicielle vont probablement se multiplier, car elles offrent un effet multiplicateur élevé aux attaquants. Les tokens npm et les comptes mainteneurs restent des cibles faciles quand la 2FA n'est pas généralisée. Les pratiques de typosquatting et la publication de dépendances fantômes resteront des tactiques rentables pour les adversaires. En parallèle, les malwares capables de s'exécuter sur plusieurs systèmes d'exploitation via un paquet JavaScript compliquent les réponses opérationnelles.

Les priorités pour réduire le risque sont claires: renforcer la gouvernance humaine autour des paquets critiques, durcir les pipelines CI, exiger la signature des artefacts, et intégrer une surveillance active des dépendances. La résilience de l'écosystème passe aussi par une adoption plus large d'outils et de pratiques qui permettent de vérifier l'intégrité des composants utilisés.

La compromission d'Axios est un rappel brutal: la sécurité logicielle moderne dépend autant des protections techniques que d'une hygiène stricte des processus et identifiants humains. La combinaison de contrôles automatisés, de politiques organisationnelles et d'une réaction rapide en cas d'incident reste la meilleure manière de protéger les projets et les infrastructures contre ce type d'attaque.


Questions fréquentes

Comment vérifier rapidement si mon projet utilise une version compromise d'Axios ?

Cherchez axios@1.14.1 et axios@0.30.4 dans vos fichiers de lock (package-lock.json, yarn.lock). Inspectez l'arbre des dépendances pour plain-crypto-js@4.2.1 et vérifiez la présence de scripts postinstall dans node_modules/plain-crypto-js/package.json. Si votre CI conserve des artefacts ou images construites aux dates suspectes, analysez-les pour détecter binaires ou scripts nouveaux.

Quelles actions immédiates entreprendre en cas de détection d'une dépendance malveillante ?

Isoler les environnements affectés et arrêter les pipelines qui utilisent les versions compromises. Retirer ces versions des mirrors internes, forcer la rotation des secrets exposés (tokens CI, clés cloud), lancer une analyse forensique sur les machines et les logs réseau, et déployer des correctifs de dépendances en verrouillant sur des versions saines ou signées.

Mesures préventives pour les mainteneurs de paquets ?

Activer la 2FA sur les comptes npm, limiter les personnes pouvant publier, utiliser des tokens à durée limitée pour les intégrations CI, auditer les changements de mainteneur, protéger les postes des mainteneurs avec EDR et gestion centralisée des secrets, et signer les releases.

Peut-on automatiser la détection d'ajouts de dépendances malveillantes dans les pipelines CI ?

Oui. Intégrer des scans SCA qui alertent sur toute nouvelle dépendance ou sur des paquets signalés comme malveillants, configurer des politiques blocantes pour empêcher l'installation de dépendances non approuvées sans validation manuelle, et générer un SBOM à chaque build pour détecter les écarts.

Sources

Lire la suite