Attaque supply chain sur axios : sécuriser vos pipelines JavaScript dès maintenant
Intention de recherche : comprendre l'attaque supply chain qui a compromis les versions 1.14.1 et 0.30.4 d'axios sur npm et bâtir un plan d'action concret pour protéger ses pipelines JavaScript et ses secrets CI/CD.
Ce qui s'est passé
- Compte mainteneur détourné : les attaquants ont pris le contrôle du compte npm du mainteneur principal (
jasonsaayman), ont modifié l'email associé et ont publié manuellement deux versions piégées (1.14.1et0.30.4). - Dépendance fantôme
plain-crypto-js@4.2.1: ajoutée uniquement pour exécuter un scriptpostinstallqui installe un cheval de Troie avec charge utile Windows, Linux et macOS. - Propagation éclair : selon StepSecurity, la dépendance malveillante a été préparée 18 h avant, les deux branches ont été frappées à 39 minutes d'intervalle et les charges ont été précompilées pour chaque OS.
- Attribution : Google TAG relie l'opération au groupe nord-coréen UNC1069, déjà connu pour des attaques chaîne d'approvisionnement visant les portefeuilles crypto.
Pourquoi c'est critique pour les DSI/CTO
- 100 M de téléchargements hebdomadaires : axios est présent dans les front-end, les BFF, les microservices et les scripts d'automatisation ; une simple installation automatique suffit à contaminer une machine de build.
- Exécution avant la fin du
npm install: le dropper contacte le C2 (sfrclak.com:8000) en moins de deux secondes, avant même que les outils EDR aient fini leurs vérifications. - Compromission silencieuse : le package malveillant s'autodétruit et réécrit son
package.json, rendant difficile tout forensic a posteriori. - Chaînes CI/CD visées : StepSecurity Harden-Runner a détecté l'incident dans Backstage, preuve que des workflows GitHub Actions peuvent exécuter ce code s'ils n'ont pas de garde-fous réseau.
Plan d'action immédiat (0-72 h)
- Inventaire & blocage : rechercher
axios@1.14.1etaxios@0.30.4dans les lockfiles (npm, pnpm, yarn) et geler toute réinstallation automatique depuis les caches internes. - Rotation des secrets : considérer comme compromis les tokens npm, clés CI/CD, accès cloud et identifiants machine utilisés pendant l'installation.
- Analyse réseau : vérifier les journaux egress (
sfrclak.com,plain-crypto-js, connexions TCP 8000) sur les postes dev et runners. - Rebuild propre : réinstaller les environnements à partir d'images sûres plutôt que d'essayer de « nettoyer ».
Renforcement sur 30 jours
- Signer et vérifier les artefacts npm internes : activer les attestations Sigstore/SLSA pour les paquets critiques et refuser tout package non attesté.
- Séparer publication et mainteneurs : mettre en place des comptes de publication robotisés protégés par des clés FIDO2 et désactiver les uploads directs via npm CLI.
- Limiter le réseau CI/CD : appliquer des allowlists de domaines sortants pour les runners, journaliser et bloquer toute résolution DNS inattendue.
- Tester la chaîne avec du chaos engineering supply chain : simuler l'injection d'une dépendance zombie dans vos projets pour mesurer le temps de détection.
Gouvernance et KPI à suivre
- Taux de dépendances signées (objectif >80 % sur les modules critiques).
- Temps de réaction supply chain : minutes entre l'alerte et le blocage pipeline.
- Couverture des revues de dépendances : % de projets analysés par semaine via OSS Review Toolkit ou Renovate.
- Rotation automatique des secrets CI/CD : fréquence et preuve d'exécution.
Conclusion
L'incident axios prouve que les attaquants ciblent désormais les dépendances utilisées par tous, pas seulement les bibliothèques obscures. Seules les organisations qui industrialisent la supervision supply chain (attestations, cloisonnement réseau, rotation de secrets) pourront continuer à shipper vite sans servir de vecteur à une opération tierce.
FAQ
Suis-je impacté si j'utilise une version packagée par un vendor SaaS ?
Oui, si ce vendor a construit son artefact pendant la fenêtre compromise. Demandez-lui une preuve de reconstruction propre.
Installer axios à partir d'un cache privé suffit-il à me protéger ?
Non, si le cache a déjà aspiré les versions piégées. Purgez-le et forcez un npm cache clean --force.
Faut-il bloquer axios ?
Non, mais épinglez temporairement une version vérifiée (1.14.0 ou 1.13.x) et attendez la communication officielle du projet avant de déployer un patch.
Comment détecter un runner compromis ?
Surveillez les connexions sortantes vers des domaines inconnus, les scripts PowerShell/Bash exécutés durant postinstall, et comparez les checksums de vos artefacts.
Sources
- The Register – « Supply chain blast: Top npm package backdoored to drop dirty RAT on dev machines » (31 mars 2026)
- StepSecurity – « axios Compromised on npm – Malicious Versions Drop Remote Access Trojan » (31 mars 2026)