Le 31 mars 2026, un simple fichier mal configuré a exposé 512 000 lignes du code source propriétaire d’Anthropic au public. Il n’y a pas eu de piratage, pas d’attaque sophistiquée, juste un paramètre négligé dans une configuration de build. C’est ce qu’il a fallu pour que les détails internes de Claude Code soient accessibles à quiconque possédant un compte npm.
Si vous utilisez le développement logiciel assisté par IA partout dans votre entreprise, cet incident vous apprend quelque chose d’extrêmement important. Il ne s’agit pas d’Anthropic, mais de ce que votre propre pipeline pourrait exposer silencieusement dès maintenant. Aujourd’hui, nous allons parler de la manière de comprendre et, par conséquent, de minimiser ces nouveaux risques.
Ce qui s’est réellement passé avec la
Ce qui s'est réellement passé avec la fuite de Claude Code
Voici un bref résumé : Anthropic distribue Claude Code sous la forme d’un package npm fermé, obfusqué. Le 30 mars 2026, ils ont publié la version 2.1.88, et enfoui dans ce package se trouvait un fichier de source map, cli.js.map, qui pointait vers la source TypeScript complète et non obfusquée.
Le chercheur en sécurité Chaofan Shou a été le premier à le signaler publiquement le 31 mars, découvrant que l’intégralité du code source de Claude Code avait été exposée via un fichier de source map publié sur le registre npm. En quelques heures, le code a été archivé sur GitHub et mis en miroir sur Internet.
La base de code divulguée comprenait près de 2 000 fichiers TypeScript et plus de 512 000 lignes de code. Le dépôt GitHub où il a été sauvegardé a dépassé 84 000 étoiles et 82 000 forks.
Anthropic a confirmé l’incident : un porte-parole a déclaré au Register qu’il s’agissait « d’un problème d’empaquetage de version causé par une erreur humaine, et non d’une violation de sécurité », et qu’aucune donnée client ni aucun identifiant n’étaient impliqués.
C’est une conséquence classique d’une erreur humaine et l’une des nombreuses raisons pour lesquelles les développeurs utilisent l’automatisation aujourd’hui. Cependant, l’automatisation complète du processus de publication aurait-elle permis d’éviter ce problème ? Plongeons plus profondément dans cette fuite de Claude Code et ses implications pour l’automatisation et le développement de l’IA à grande échelle.
Les mécanismes techniques : pourquoi la fuite de Claude Code a été si facile à manquer
Si vous n’êtes pas développeur, voici la version courte de la manière dont de telles choses peuvent se produire. Lorsque les ingénieurs créent des applications JavaScript ou TypeScript, le code est intentionnellement regroupé et minifié (compressé en quelque chose à peine lisible). Les fichiers de source map sont des outils de débogage qui inversent ce processus. Ils permettent de faire correspondre la sortie minifiée au code source d’origine. C’est très utile sur votre machine, mais cela devient une vulnérabilité en production.
Selon l’analyse du code source exposé de Claude Code, la fuite résultait d’une référence à une source TypeScript non obfusquée dans le fichier de map inclus dans le package npm.
Un simple .npmignore mal configuré ou un champ de fichiers dans package.json peut tout exposer.
C’est tout ce qu’il faut, un seul fichier ou une exclusion manquée, et vous êtes dans un monde de problèmes. Dans le cas d’Anthropic, la chaîne de build (probablement Bun) a généré des source maps qui n’ont pas été exclues de l’artefact publié, donc la configuration .npmignore ne les prenait pas en compte. Pensez-y comme ceci : c’est comme imprimer votre feuille de route interne au dos de chaque produit que vous expédiez. Le produit fonctionne bien, mais quiconque le retourne connaît maintenant tout.
C’est ce qui rend la fuite de Claude Code si instructive pour les équipes d’ingénierie. L’échec n’a pas été causé par une combinaison de facteurs extrême et exotique, mais plutôt par le genre de chose qui arrive dans toute équipe en évolution rapide qui publie fréquemment. La seule façon fiable de détecter des problèmes similaires est d’avoir les bons contrôles en place avant la publication, pas après.
Qu'y avait-il dans le code Claude divulgué ?
La fuite contenait la propriété intellectuelle et la feuille de route interne d’Anthropic, en quasi-totalité. Voici ce que la communauté a découvert dans ces 1 906 fichiers TypeScript :
Architecture et outils :
- Une architecture d’outils basée sur des plugins avec environ 40 outils discrets (lecture de fichiers, exécution bash, intégration LSP), chacun soumis à des permissions
- Un moteur de requête de 46 000 lignes gérant tous les appels aux API des LLM, le streaming, la mise en cache et les boucles d’appels d’outils
- Une logique d’orchestration multi-agents qui était auparavant non documentée
Fonctionnalités non publiées :
- Une fonctionnalité nommée KAIROS, un agent de fond persistant capable de corriger des erreurs périodiquement ou d’exécuter des tâches de manière autonome, en envoyant des notifications push sans attendre l’entrée de l’utilisateur. Elle est complétée par un mode « rêve » qui permet à Claude de développer continuellement des idées en arrière-plan.
- Un animal de compagnie compagnon de type Tamagotchi (une espèce déterministe basée sur le hash de votre ID utilisateur), dont la sortie interne est prévue pour avril 2026 et le lancement complet pour mai 2026.
De plus, le « mode sous couverture » révélé dans le code divulgué montre qu’Anthropic utilise Claude Code pour apporter des contributions furtives à des dépôts open-source publics. Le prompt système pour ce mode se lit comme suit : « Vous opérez SOUS COUVERTURE dans un dépôt PUBLIC/OPEN-SOURCE. Vos messages de commit, titres de PR et corps de PR NE DOIVENT PAS contenir D’informations internes à Anthropic. Ne dévoilez pas votre couverture. »
Ce détail, en particulier, a suscité le plus de controverse au sein de la communauté des développeurs, car il représente un agent IA opérant incognito sur des dépôts publics, par conception. Que vous trouviez cela préoccupant ou non, l’important est que cette information n’était pas censée être publique. Cependant, elle est maintenant gravée à jamais dans la mémoire d’Internet.
En outre, la fuite de Claude Code a révélé les détails internes des performances du modèle. Le code confirme que Capybara est le nom de code interne d’une variante de Claude 4.6, les développeurs notant un taux de fausses déclarations de 29-30 % dans la v8, ce qui constitue une régression réelle par rapport au taux de 16,7 % observé dans la v4. Les développeurs ont également noté un « contre-poids d’assertivité » conçu pour empêcher le modèle de devenir trop agressif dans ses refactorisations. Pour les concurrents, c’est une nouvelle référence, et pour les chercheurs en sécurité, c’est une carte indiquant où se trouvent les garde-fous et comment ils fonctionnent.
La plus grande menace : l'attaque de la chaîne d'approvisionnement Axios
C’est là que l’histoire devient plus sérieuse pour votre propre équipe. La fuite de Claude Code a été embarrassante pour Anthropic, mais ce n’était pas une violation de sécurité directe pour les utilisateurs. Cependant, l’attaque Axios concomitante était une menace de premier plan.
Les 30-31 mars 2026, le package npm Axios a été compromis dans l’une des attaques les plus importantes de la chaîne d’approvisionnement npm à ce jour. Avec plus de 100 millions de téléchargements hebdomadaires, Axios est un client HTTP fondamental utilisé dans tout l’écosystème JavaScript. Un attaquant a détourné le compte npm du principal mainteneur et a publié deux versions malveillantes qui ont déployé un cheval de Troie d’accès à distance (RAT) multiplateforme sur toute machine qui exécutait npm install.
Les utilisateurs qui ont installé ou mis à jour Claude Code via npm le 31 mars 2026, entre 00h21 et 03h29 UTC, ont pu involontairement télécharger une version malveillante d’axios (1.14.1 ou 0.30.4) contenant un cheval de Troie d’accès à distance. Les utilisateurs doivent immédiatement rechercher dans les fichiers de verrouillage de projet ces versions spécifiques ou la dépendance plain-crypto-js.
Microsoft Threat Intelligence a attribué le compromis du package npm Axios à Sapphire Sleet, un acteur étatique nord-coréen. Ce n’était pas une frappe opportuniste. Au contraire, c’était ciblé, chronométré et conçu pour un rayon d’action maximal.
L’attaque a fonctionné parce qu’elle a exploité un déficit de confiance qui existe dans presque tous les projets JavaScript modernes : l’attaquant a utilisé un jeton d’accès npm volé de longue durée pour publier directement sur le registre npm, contournant complètement les pipelines CI/CD. Les versions légitimes d’Axios incluent des métadonnées de provenance OIDC qui lient le package npm à une exécution spécifique de GitHub Actions. Les versions malveillantes n’en avaient aucune, car elles ont été publiées directement, ne laissant aucune trace de build vérifiable. La majorité des équipes n’auraient eu aucune idée que quelque chose n’allait pas.
Ce que révèlent les deux incidents sur votre pipeline
Deux incidents distincts le même jour, avec le même écosystème de packages. Ce n’est pas une coïncidence, mais un schéma. Et cela met en évidence un ensemble de risques structurels qui existent dans la plupart des pipelines de développement modernes.
- Fuite d’artefacts de build
La plupart des équipes n’exécutent jamais npm pack –dry-run avant de publier. Elles font confiance à la chaîne de build pour faire ce qu’il faut. L’équipe d’Anthropic aussi, d’où la fuite de Claude Code. Les fichiers de source maps, les configurations internes, les fichiers .env.example avec des valeurs réalistes, tout cela peut se retrouver dans un package publié sans que personne ne s’en aperçoive. - Ignorance des dépendances tierces
L’analyse des attaques de 2025-2026 révèle un schéma constant : les attaquants obtiennent un premier accès via des identifiants compromis, et la même chaîne d’attaque se répète. Les mainteneurs sont victimes de hameçonnage, les identifiants sont abusés, et le code malveillant persiste trop longtemps avant que quelqu’un ne le détecte. Claude Code utilisait Axios, et votre application le fait probablement aussi. - Sur-dépendance aux installations automatisées
Exécuter npm install dans un pipeline CI/CD sans aucune vérification de provenance, d’épinglage de version, ou de suivi SBOM est la norme pour la plupart des équipes. C’est aussi ainsi qu’un RAT se retrouve sur la machine de vos développeurs sans un seul clic suspect. - Portes de publication manquantes
La leçon de la fuite de Claude Code est claire : .npmignore est porteur de charge. Traitez-le comme une frontière de sécurité. La plupart des équipes d’ingénierie n’ont aucune étape d’examen formelle entre “build” et “publish”. Cet écart est l’endroit où ces incidents se produisent.
Ce n’est pas tout hypothétique ; par exemple, en septembre 2025, des attaquants ont détourné 18 packages npm populaires téléchargés collectivement plus de 2 milliards de fois par semaine. Ces attaques se produisent à grande échelle et touchent de vraies équipes.
Ce que votre équipe devrait faire maintenant
Voici ce qu’un audit de votre pipeline devrait couvrir, compte tenu de ce que le 31 mars a révélé :
Auditez votre configuration npm publish avant votre prochaine publication. Exécutez npm pack –dry-run et inspectez chaque fichier qui serait expédié. Recherchez :
- Tous les fichiers .map dans dist/
- Les répertoires sources inclus accidentellement
- Les fichiers de configuration contenant des chemins ou des jetons internes
Considérez votre .npmignore comme une frontière de sécurité et incluez-le dans chaque checklist de publication.
Épinglez vos dépendances critiques en retirant les chevrons (^) et les tildes (~) de package.json pour les bibliothèques comme Axios qui se trouvent profondément dans votre arbre de dépendances. Microsoft recommande de désactiver les fonctionnalités de mise à jour automatique pour les packages npm dans les organisations où la posture de sécurité exige un examen avant le déploiement.
Vérifiez vos lockfiles maintenant si vous ou votre équipe avez exécuté npm install le 31 mars 2026, entre 00:21 et 03:29 UTC, recherchez immédiatement dans vos lockfiles :
grep -r "1.14.1|0.30.4|plain-crypto-js" package-lock.jsonExigez des vérifications de provenance npm publish et un niveau SLSA 2+ pour tous les packages internes et tiers critiques. L’absence de provenance OIDC sur une nouvelle version d’un package majeur devrait déclencher une alerte automatique. La plupart des équipes n’ont pas configuré cela, mais c’est parce qu’elles n’en avaient pas encore besoin.
Ajoutez une étape de revue de publication à votre pipeline CI/CD pour chaque version. Intégrez une étape d’inspection des artefacts avant publication qui vérifie la présence de source maps, d’URL de débogage et de directives sourceMappingURL dans votre sortie distribuée finale.
Revoyez votre utilisation des outils de codage IA dans les environnements sensibles et adoptez une posture de confiance zéro lors de l’utilisation de Claude Code dans des environnements inconnus. Évitez d’exécuter l’agent dans des dépôts fraîchement clonés ou non fiables avant d’avoir inspecté manuellement .claude/config.json et tout hook personnalisé. La même logique s’applique à tout outil IA disposant d’un accès au système de fichiers et au shell. C’est quelque chose que nous avons expliqué en détail dans notre article sur les bonnes pratiques de sécurité OpenClaw.
La question plus large : que savez-vous de votre pipeline ?
La plupart des fondateurs et des responsables de l’ingénierie peuvent décrire l’architecture de leur produit en détail. Moins nombreux sont ceux qui peuvent décrire, avec la même assurance, exactement ce que leur pipeline CI/CD déploie, à quelles dépendances il fait confiance automatiquement, et ce qu’un acteur malveillant avec un jeton npm compromis pourrait présenter à leurs développeurs demain.
La clé pour prévenir des incidents comme la fuite de Claude Code est de mettre en place les bons processus de révision afin de pouvoir déployer rapidement sans risque caché. Un audit logiciel professionnel, couvrant la configuration de votre build, la chaîne de dépendances, le pipeline CI/CD et le processus de publication, prend quelques jours, pas des semaines. L’incident Anthropic a mis des heures à se dérouler, et la fenêtre d’attaque d’Axios n’a duré que 39 minutes.
Si vous utilisez des outils de développement assistés par l’IA et que vous souhaitez garantir la sécurité et la bonne gouvernance du pipeline qui les entoure, c’est précisément le type de travail que Redwerk effectue pour les entreprises technologiques depuis 2005. Notre service de revue de code comprend la configuration des builds et des dépendances, et notre consulting DevOps couvre le renforcement de la CI/CD qui rend les incidents de ce type beaucoup moins susceptibles d’affecter votre équipe.
La fuite de Claude Code est survenue en raison d’un seul fichier mal configuré. L’attaque Axios a réussi à cause d’un compte compromis et d’un jeton npm non contrôlé. Ce sont tous deux des échecs mineurs au niveau des processus que les équipes intelligentes négligent jusqu’à ce qu’elles ne le puissent plus.
Ce que le 31 mars a réellement révélé, ce n’est pas qu’Anthropic a fait une erreur. C’est que le pipeline de développement JavaScript moderne, avec ses arbres de dépendances denses, ses installations automatisées et ses registres de packages qui font confiance par défaut, est beaucoup plus exposé que la plupart des équipes ne le réalisent. Et plus vous déployez rapidement, plus il est probable qu’une de ces failles existe quelque part entre votre code et vos utilisateurs. Si vous êtes prêt à prévenir cela dans votre pipeline, contactez-nous, et fermons ensemble toutes les brèches de votre sécurité.
Découvrez comment nous avons aidé le projet Science de Complete Network à améliorer la maintenabilité du code de 80 %
