Compromission du package npm Axios : comment protéger vos projets contre les attaques Supply Chain

Le package npm axios, pilier du développement web moderne, a été la cible d'une compromission majeure via une attaque par chaîne d'approvisionnement. Cet incident rappelle que même les outils les plus fiables peuvent devenir des vecteurs d'infection si l'on ne surveille pas activement ses dépendances.

C'est l'une des hantises de tout CTO ou développeur : voir une bibliothèque de confiance, utilisée par des millions de projets, se transformer en cheval de Troie. C'est exactement ce qui vient de se passer avec axios, le client HTTP le plus populaire de l'écosystème JavaScript. Avec plus de 100 millions de téléchargements par semaine, l'impact potentiel d'une telle faille est colossal.

Chez Fragments Studio, nous suivons de près ces vulnérabilités pour sécuriser les infrastructures de nos clients. Voici l'analyse de cette attaque, ses risques et les mesures concrètes à prendre immédiatement.

L'attaque Supply Chain sur Axios : que s'est-il passé ?

Une attaque par chaîne d'approvisionnement (ou Supply Chain Attack) est une cyberattaque qui cible les éléments tiers d'un logiciel — comme une bibliothèque open-source — pour infecter les utilisateurs finaux.

Dans le cas récent d'axios, la compromission n'est pas venue d'une faille de code dans le projet lui-même, mais d'une prise de contrôle du compte d'un mainteneur sur le registre npm.

L'attaquant a publié des versions malveillantes (notamment les versions 1.14.1 et 0.30.4) contenant une dépendance cachée nommée plain-crypto-js. Ce package, en apparence anodin, contenait en réalité un Remote Access Trojan (RAT) multiplateforme.

La particularité technique de cette attaque réside dans sa discrétion. Aucun fichier source d'axios n'a été modifié sur GitHub. Le code malveillant a été injecté directement lors de la publication sur npm, utilisant le hook postinstall pour exécuter le malware dès que l'utilisateur lance une commande npm install.

Pourquoi Axios est-il une cible prioritaire ?

Plus une bibliothèque est populaire, plus elle devient une cible de choix pour les attaquants. Axios est présent dans la quasi-totalité des projets web modernes, qu'il s'agisse de frontend (React, Vue, Next.js) ou de backend (Node.js).

Le concept de blast radius (rayon d'impact) est ici maximal : en infectant un seul package, l'attaquant accède potentiellement à des millions de serveurs et de machines de développement.

Selon les rapports récents de sécurité, les attaques sur la chaîne d'approvisionnement logicielle ont augmenté de plus de 200 % ces dernières années, car elles permettent de contourner les pare-feu d'entreprise en passant par la porte d'entrée des développeurs.

Chez Fragments Studio, nous intégrons systématiquement ces problématiques dans nos développements sur mesure, car la sécurité ne commence pas au déploiement, mais dès le choix des dépendances.

Quels sont les risques pour votre entreprise ?

Une compromission via un package npm n'est pas un simple bug ; c'est une intrusion profonde dans votre système. Les risques se déclinent en trois niveaux :

1. Exfiltration de données sensibles : Le malware injecté est capable de scanner vos fichiers .env et de voler vos clés d'API, vos accès aux bases de données ou vos jetons de service.
2. Compromission de la CI/CD : Si votre pipeline de déploiement automatique télécharge la version infectée, l'attaquant peut potentiellement injecter du code malveillant directement dans votre produit final envoyé aux clients.
3. Contrôle à distance (RAT) : Le cheval de Troie permet à l'attaquant de prendre le contrôle de la machine infectée, d'exécuter des commandes arbitraires et de se propager latéralement sur votre réseau interne.

Il est crucial de comprendre qu'un développeur ayant installé ces versions malveillantes doit considérer sa machine de travail comme totalement compromise.

5 règles d'or pour se protéger (aujourd'hui et demain)

Face à ce type de menace, la vigilance manuelle ne suffit plus. Voici les bonnes pratiques que nous appliquons pour sécuriser nos projets web.

1. Vérifiez vos versions et utilisez les lockfiles

La première étape est de vérifier si votre projet utilise une version compromise. Utilisez la commande suivante pour inspecter votre arbre de dépendances : npm list axios.

Assurez-vous que votre fichier package-lock.json ou yarn.lock est bien présent et versionné. Ces fichiers garantissent que tous les membres de l'équipe et vos serveurs installent exactement la même version des dépendances, évitant ainsi les mises à jour automatiques vers des versions mineures infectées.

2. Imposez des versions fixes pour les packages critiques

Par défaut, npm utilise le préfixe caret (^) qui autorise les mises à jour mineures. Pour des packages aussi sensibles qu'axios, préférez fixer la version exacte (ex: 'axios': '1.14.0') dans votre package.json. Cela vous donne le temps de valider chaque mise à jour.

3. Automatisez l'audit de sécurité

Intégrez l'outil npm audit ou des solutions comme Snyk ou Socket.dev dans vos workflows GitHub Actions. Ces outils bloquent automatiquement les pull requests qui tentent d'introduire des packages connus pour être malveillants ou vulnérables.

4. Nettoyez les dépendances inutilisées

Moins vous avez de dépendances, moins votre surface d'attaque est grande. Utilisez des outils comme depcheck pour identifier et supprimer les packages qui ne sont plus nécessaires à votre projet.

5. Utilisez des tokens éphémères pour la CI/CD

Ne stockez jamais de jetons npm de longue durée dans vos environnements de développement ou de déploiement. Privilégiez le Trusted Publishing (OIDC) qui permet d'utiliser des jetons à courte durée de vie, réduisant ainsi le risque en cas de fuite de credentials.

Questions fréquentes

Comment savoir si mon projet a été infecté par Axios ?

Exécutez npm list axios. Si vous voyez les versions 1.14.1 ou 0.30.4, votre projet a téléchargé le code malveillant. Vérifiez également la présence d'un package nommé plain-crypto-js dans votre dossier node_modules.

Est-ce que supprimer le package suffit à nettoyer mon ordinateur ?

Non. Si le malware s'est exécuté (via le script postinstall), il a pu installer des mécanismes de persistance. La recommandation de sécurité standard en cas d'infection par un RAT est de réinitialiser la machine et de changer tous les mots de passe et clés d'API stockés dessus.

Pourquoi npm ne bloque-t-il pas ces packages immédiatement ?

npm réagit rapidement une fois le signalement effectué, mais il y a souvent un délai de quelques heures entre la publication et la suppression. C'est durant cette fenêtre que les attaques font le plus de dégâts sur les projets automatisés.

Existe-t-il des alternatives plus sûres à Axios ?

L'alternative principale est l'API native fetch, disponible dans les navigateurs et Node.js moderne. Elle ne nécessite aucune dépendance externe, ce qui réduit drastiquement les risques de supply chain attack. Cependant, Axios reste un excellent outil s'il est correctement verrouillé.

Conclusion

L'incident axios est un rappel brutal : la sécurité de votre produit dépend de la sécurité de chacun de ses composants tiers. En 2025, la gestion des dépendances ne peut plus être une tâche de second plan. Elle doit être intégrée au cœur de votre Developer Experience et de votre stratégie de risque.

Chez Fragments Studio, nous accompagnons nos partenaires dans la sécurisation de leur stack technique, de l'audit de dépendances à la mise en place de pipelines CI/CD robustes. La confiance n'exclut pas le contrôle.

---

Sécurisez votre infrastructure logicielle dès maintenant

La sécurité de vos dépendances est un enjeu critique pour la pérennité de votre entreprise.

• Découvrez notre expertise en développement web pour des applications robustes et sécurisées.
• Si votre projet nécessite une refonte technique pour limiter les risques, notre équipe développement sur mesure peut vous accompagner.
• Obtenez une première évaluation de votre stack via notre estimateur de projet.
• Ou parlons-en directement pour auditer vos process de sécurité.