Secu
D’Anthropic à Axios : NPM, le maillon faible de vos chaînes logicielles
Par Laurent Delattre, publié le 03 avril 2026
En moins de vingt-quatre heures, « npm » s’est retrouvé au centre de deux affaires sans rapport apparent mais très révélatrices. Chez Anthropic, une erreur d’empaquetage a exposé le code source de Claude Code. Dans l’écosystème Axios, une compromission de compte mainteneur a transformé une bibliothèque ultra-populaire en cheval de Troie multiplateforme. Deux événements qui s’inscrivent dans une série noire entamée depuis des mois et, en plein Forum InCyber 2026, invitent aussi les DSI à se requestionner sur la sécurité de leur chaîne d’approvisionnement logicielle.
NPM, pour Node Package Manager, est à la fois l’outil en ligne de commande, le site et surtout le registre public sur lequel les développeurs publient et récupèrent des paquets JavaScript. La documentation officielle le présente comme le plus grand registre logiciel au monde. Dit autrement, c’est un gigantesque entrepôt numérique où les développeurs publient et récupèrent les bibliothèques logicielles dont leurs applications ont besoin. Quasiment tout projet JavaScript moderne en dépend : une simple commande « npm install » suffit à tirer des dizaines de dépendances depuis ce registre, chacune pouvant elle-même en appeler d’autres, formant des chaînes de dépendances profondes et souvent opaques. Il permet de réutiliser du code, d’assembler rapidement des applications, de gérer les dépendances et de diffuser des mises à jour à l’échelle de l’écosystème. Cette mécanique rend NPM extraordinairement pratique, mais aussi extraordinairement risqué. Dès qu’un paquet très utilisé, un compte mainteneur ou une chaîne de publication sont altérés, le rayon d’impact potentiel devient colossal.
Preuve en est l’actualité cyber de la semaine. En quelques heures, deux incidents de cybersécurité majeurs, de nature radicalement différente mais partageant NPM en même vecteur ont frappé la communauté des développeurs.
D’un côté, Anthropic a involontairement publié l’intégralité du code source de Claude Code, son outil de programmation assistée par IA, via un fichier source map oublié dans un paquet NPM. Un méchant leak lié à une erreur de manipulation.
De l’autre, des attaquants ont pris le contrôle du compte du mainteneur principal de la bibliothèque Axios, téléchargée plus de 100 millions de fois par semaine, pour y injecter un cheval de Troie multiplateforme.
Des incidents qui ne sont pas malheureusement pas isolés et surviennent après une série d’attaques portées via et contre NPM. Ces derniers mois, l’écosystème a, en effet, été secoué par la vague Shai-Hulud, qui a touché au moins 187 paquets en septembre 2025 avant de s’étendre à des centaines de packages et d’exposer jusqu’à 400 000 secrets de développeurs fin 2025. Début mars 2026, la campagne PhantomRaven a encore montré que des dizaines de paquets malveillants pouvaient rester actifs pour siphonner des données de développeurs et des secrets CI/CD.
Autant d’incidents qui ont transformé NPM en sujet de résilience opérationnelle.
Claude Code : une fuite par erreur humaine, pas une compromission
L’incident Anthropic n’est certes pas “offensif”, mais il n’en est pas moins sérieux. Le 31 mars 2026, Anthropic a brièvement publié sur npm la version 2.1.88 de Claude Code avec un fichier cli.js.map d’environ 60 Mo. Ce fichier, normalement réservé au débogage interne n’est pas un simple détail technique : lorsqu’il embarque le champ sourcesContent, il permet de reconstituer l’arborescence et le contenu du code source original. D’après les éléments publiés, l’exposition concernait environ 1 900 fichiers et 512 000 lignes de code. Anthropic a reconnu l’incident, indiqué qu’aucune donnée client ni aucun identifiant n’avaient été exposés, et l’a qualifié de problème d’empaquetage dû à une erreur humaine (à moins qu’il ne soit une erreur de sa propre IA agentique), non à une intrusion.
Mais le mal était fait. En quelques heures, le code a été répliqué sur GitHub, accumulant plus de 84 000 étoiles et 82 000 forks avant qu’Anthropic ne lance ses demandes de retrait, en vain puisque des miroirs décentralisés ont rapidement été mis en ligne.
Cette fuite ne relève pas d’une cyber attaque, mais d’une hygiène de build insuffisante au moment de la publication. Des développeurs ont immédiatement commencé à fouiller le code, à y repérer des fonctions non documentées, et à déchiffrer ce que l’IA cherchait à obtenir comme données de contexte sur les utilisateurs et les machines. Des petits malins se sont même amusés à demander à Claude de réécrire « Claude Code » en Python, affirmant que ces versions « transposées » par l’IA ne violait pas de copyright, prenant quelque peu Anthropic à son propre jeu du « non, l’IA ne plagie pas les codes qui ont servi à son entraînement ». On est donc face à une fuite accidentelle de propriété intellectuelle et de surface d’attaque, plus qu’à une compromission.
Axios : la version brutale de l’attaque supply chain
L’affaire Axios est d’une autre nature et d’une autre gravité opérationnelle. Le même jour, des attaquants ont pris le contrôle du compte npm du mainteneur principal d’Axios et publié deux versions piégées, axios@1.14.1 et axios@0.30.4. Axios est l’un des clients HTTP JavaScript les plus utilisés au monde (il est présent dans React, Vue et Angular notamment), avec plus de 100 millions de téléchargements hebdomadaires. Selon les chercheurs de Wiz, il est présent dans environ 80 % des environnements cloud et de code. Les versions malveillantes sont restées en ligne environ trois heures avant d’être retirées.
Le point clé est que le code d’Axios lui-même n’a pas été modifié. Les attaquants ont injecté une dépendance fantôme, plain-crypto-js@4.2.1, dont l’unique fonction était d’exécuter un script postinstall. Ce script déposait ensuite une charge utile différente selon l’OS : AppleScript et binaire sur macOS, PowerShell et chargeur en mémoire sur Windows, script Python sur Linux. Le tout installait un cheval de Troie type RAT (Remote Access Trojan), contactait un serveur de commande et contrôle, puis effaçait ses traces en remplaçant les fichiers malveillants par des versions propres afin de compliquer la forensic. Plusieurs chercheurs et Google GTIG ont estimé que l’opération présentait des similarités avec des modes opératoires nord-coréens, tout en restant prudents sur l’attribution définitive.
Cette attaque est d’autant plus intéressante qu’elle a contourné les garde-fous modernes sans les “casser”. Les publications légitimes d’Axios passaient par GitHub Actions avec OIDC Trusted Publisher, alors que les versions malveillantes ont été poussées manuellement avec un compte npm compromis, sans trace côté dépôt GitHub. Autrement dit, le problème n’était pas l’absence totale de sécurité, c’était la coexistence entre des mécanismes modernes et des accès hérités toujours exploitables. C’est exactement le type de faille organisationnelle que les équipes de sécurité sous-estiment encore trop souvent.
Deux affaires npm, deux leçons
Ces deux incidents cristallisent les failles structurelles d’un écosystème dont la puissance fait aussi sa fragilité. Comme trop souvent sur ces couches open source fondamentales, NPM repose fondamentalement sur la confiance : confiance dans les mainteneurs, confiance dans l’intégrité des paquets, confiance dans les chaînes de dépendances. Or cette confiance est systématiquement exploitée par les attaquants.
Les deux incidents racontent en réalité deux histoires différentes. Chez Anthropic, npm a servi de canal de diffusion à une erreur (humaine ou agentique, peu importe) de packaging. Chez Axios, npm a servi de canal de diffusion à une compromission de compte mainteneur et à une attaque supply chain sophistiquée.
La bonne nouvelle, c’est que l’écosystème npm dispose déjà de plusieurs briques de défense. Plutôt que de s’appuyer sur des jetons d’accès permanents (l’équivalent numérique d’une clé de maison qu’on laisserait sous le paillasson) la plateforme recommande désormais un système d’authentification plus moderne appelé « trusted publishing ». Le principe : au lieu de confier un mot de passe longue durée à un développeur, on génère un accès temporaire et limité à chaque publication, directement lié à l’environnement de travail vérifié (comme GitHub Actions). NPM encourage également l’activation systématique de la double authentification et la vérification de provenance, qui permet de s’assurer qu’un paquet a bien été publié depuis la chaîne de production officielle d’un projet et non depuis la machine d’un inconnu. L’incident Axios illustre parfaitement pourquoi ces précautions sont indispensables : le projet utilisait bien le système moderne pour ses publications légitimes, mais un ancien jeton d’accès (jamais révoqué) traînait encore dans la nature. C’est par cette porte latérale que les attaquants se sont engouffrés.
Côté entreprises, les bonnes pratiques à adopter sont pourtant bien documentées. Il faut impérativement verrouiller les versions exactes des dépendances et proscrire les plages flottantes (^1.14.0 ou ~1.14.0), utiliser « npm ci » plutôt que « npm install » dans les pipelines CI/CD pour respecter strictement le lockfile, désactiver les scripts de cycle de vie (–ignore-scripts) quand ils ne sont pas indispensables, et mettre en place une politique de « refroidissement » refusant les paquets publiés depuis moins de quelques jours. La vérification de la provenance des paquets via SLSA (Supply-chain Levels for Software Artifacts) devient également un signal critique : la version légitime d’Axios 1.14.0 avait été publiée via GitHub Actions avec une attestation OIDC Trusted Publishing, tandis que la version malveillante 1.14.1 avait été publiée manuellement avec un jeton volé, sans aucune trace dans le dépôt GitHub officiel. Ce décalage dans la méthode de publication est un indicateur de compromission que les systèmes automatisés peuvent et doivent vérifier.
La leçon de fond est assez brutale : dans les chaînes logicielles modernes, la sécurité ne se joue plus seulement dans le code, mais dans la publication, l’empaquetage, les dépendances et les identités qui tiennent tout cela ensemble. Les solutions techniques existent pour vous y aider, mais le défi est ici surtout organisationnel puisqu’il impose de définir une gouvernance à 360° et des contrôles de sécurité modernes.
À LIRE AUSSI :
À LIRE AUSSI :
