Fuite de la carte source du code Claude, ce qui a été exposé et ce que cela signifie

Claude Code n'est pas devenu une nouvelle parce que quelqu'un a trouvé une erreur dans le frontend. Il est devenu une nouvelle parce que des rapports publics du 31 mars ont déclaré que l'interface de programmation distribuée npm d'Anthropic exposait suffisamment de métadonnées de carte de source pour que des personnes extérieures puissent reconstruire une source TypeScript lisible, et que de multiples miroirs GitHub publics sont apparus presque immédiatement en affirmant qu'ils étaient dérivés de cli.js.map pour @anthropic-ai/claude-code version 2.1.88. Le journal des modifications d'Anthropic et les versions GitHub montrent que 2.1.88 comme une véritable version publique datée du 30 mars 2026, qui correspond à la version nommée dans ces miroirs. (X (anciennement Twitter))

Cela ne signifie pas que toutes les affirmations effrayantes qui circulent en ligne sont vraies. Les preuves publiques les plus solides soutiennent un événement de conditionnement et d'exposition d'artefacts : un artefact de débogage ou de mappage associé à l'interface de programmation distribuée semble avoir été suffisant pour permettre une reconstruction substantielle de la source. C'est déjà grave. Mais ce n'est pas la même chose qu'une violation confirmée des systèmes en nuage d'Anthropic, et ce n'est pas la même chose qu'une divulgation prouvée de référentiels clients, d'invites ou de fichiers locaux. Des cas similaires de cartographie des sources, y compris un avis Astro de 2024, ont été traités en premier lieu comme des manquements à la confidentialité et seulement en second lieu comme des accélérateurs pour des recherches d'exploitation ultérieures. (GitHub)

Un détail mérite d'être souligné. Les miroirs publics et les messages sociaux originaux sont des preuves solides que l'exposition a eu lieu. Les pages publiques actuelles de consultation des paquets sont une preuve plus faible que le même artefact est toujours accessible aujourd'hui. Par exemple, jsDelivr affiche actuellement @anthropic-ai/claude-code version 2.1.88 et énumère cli.jsmais n'énumère pas de manière évidente cli.js.map dans la page de navigation publique. Cela ne réfute pas l'événement. Cela signifie qu'un rapport rigoureux doit séparer l'allégation d'exposition historique de la question de l'accessibilité actuelle. (jsDelivr)

La lecture du courant le plus propre ressemble à ceci.

Question	Réponse la mieux étayée à l'heure actuelle
La source Claude Code a-t-elle été exposée sous une forme reconstituable ?	Oui, les miroirs publics publiés le 31 mars indiquent qu'ils ont été reconstitués à partir des données de la base de données de la Commission européenne. cli.js.map pour @anthropic-ai/claude-code 2.1.88
Est 2.1.88 une véritable publication officielle du code Claude	Oui, le changelog public d'Anthropic et les versions GitHub montrent que 2.1.88 publié le 30 mars 2026
L'histoire publique implique-t-elle des artefacts de distribution npm ?	Oui, les miroirs publics lient explicitement la reconstruction des sources au paquet publié par npm.
Est un r2.dev URL de l'objet techniquement capable de servir des fichiers publics	Oui, documents Cloudflare r2.dev comme URL de développement public pour les buckets R2 lorsque l'accès public est activé
La page de navigation publique du CDN publiée aujourd'hui prouve-t-elle que la carte est toujours accessible ?	Non, les pages consultées actuellement ne sont pas suffisantes pour répondre à cette question.

Le tableau ci-dessus est basé sur les données de publication d'Anthropic, la documentation R2 de Cloudflare, les métadonnées des miroirs de paquets actuels et les référentiels de reconstruction publics publiés après l'événement. (GitHub)

Pourquoi une carte des sources peut-elle transformer un paquet en source lisible ?

Une carte des sources n'est pas magique. Il s'agit d'un fichier structuré qui relie le code JavaScript transformé ou regroupé au code source original. MDN décrit les cartes de source comme des fichiers JSON qui relient le code transformé à la source originale non modifiée, de sorte que l'original puisse être reconstruit et utilisé pour le débogage. Dans le cadre d'un développement normal, il s'agit d'une commodité. Dans un contexte de sécurité, il s'agit d'une surface d'exposition à l'information. (MDN Web Docs)

Le mécanisme est simple. Le JavaScript généré se termine généralement par un sourceMappingURL . La documentation de Sentry explique que les outils découvrant une telle directive résoudront l'URL de la carte des sources par rapport au fichier source, ou utiliseront une URL entièrement qualifiée si une URL est incorporée directement. C'est important parce qu'une fois qu'un artefact de construction publie le pointeur, le reste de la chaîne devient récupérable ou reconstructible par tout ce qui peut lire le fichier public. (Sentry Docs)

C'est précisément pour cette raison que l'OWASP considère les cartes de sources exposées comme une forme de fuite d'informations. Son guide de test de la sécurité du Web note que les cartes de source rendent le code plus lisible par l'homme et peuvent aider les attaquants à trouver des vulnérabilités ou à recueillir des informations sensibles telles que des itinéraires cachés, la structure interne ou des détails codés en dur. L'essentiel n'est pas qu'une carte des sources soit toujours catastrophique. L'essentiel est qu'elle modifie le modèle de coût de l'attaquant. Le code qui était auparavant bruyant, aplati ou difficile à raisonner devient beaucoup plus facile à étudier. (OWASP)

Voici le modèle mental simplifié qu'un défenseur doit garder à l'esprit.

{
  "version" : 3,
  "file" : "bundle.js",
  "sources" : ["src/main.ts", "src/permissions.ts", "src/remote.ts"],
  "mappings" : "..."
}

Un tel fichier peut présenter un risque faible ou élevé en fonction des autres éléments qui l'accompagnent. S'il inclut les sources originales en ligne, la divulgation est immédiate. S'il pointe vers des artefacts externes prévisibles, la divulgation peut n'être qu'une requête supplémentaire. S'il s'agit simplement d'une mise en correspondance de numéros de ligne, mais que la source originale est par ailleurs privée, l'impact est moindre. La catégorie de défaillance est plus large que "quelqu'un a téléchargé un mauvais fichier". Il s'agit de savoir si le chemin complet de l'emballage a traité les artefacts de débogage comme étant publics ou privés. (MDN Web Docs)

C'est pourquoi les conseils de Sentry sont importants. Sa documentation ne présente pas l'hébergement public comme la meilleure solution par défaut. Ils indiquent que le modèle le plus fiable consiste à télécharger les cartes sources directement dans Sentry, et que si les équipes veulent garder les cartes secrètes tout en permettant de les récupérer, elles doivent en contrôler l'accès à l'aide d'un jeton ou d'un autre mécanisme d'authentification. En d'autres termes, un outil mature suppose déjà qu'il existe des raisons légitimes de ne pas exposer publiquement les cartes des sources. (Sentry Docs)

La défaillance de l'emballage n'était pas le fait d'un seul fichier, mais d'une chaîne.

L'histoire de Claude Code, telle qu'elle a été rapportée publiquement, implique une chaîne de défaillances en plusieurs étapes plutôt qu'un accident unique. Les messages publics indiquent que la source est devenue accessible par le biais d'une .carte dans la distribution npm et un fichier r2.dev/src.zip chemin. Les miroirs publics ont alors déclaré avoir déballé cli.js.map de @anthropic-ai/claude-code 2.1.88 et reconstruit la source à partir de là. Même si certains détails du chemin public exact ne sont toujours pas résolus, la chaîne rapportée est suffisamment claire pour que l'on puisse raisonner : la sortie de la compilation, le contenu des paquets, les références aux cartes et l'exposition au stockage d'objets ont tous eu de l'importance. (X (anciennement Twitter))

La documentation R2 de Cloudflare est utile ici car elle explique le modèle d'accès sans aucune spéculation. Les buckets publics sont privés par défaut, mais lorsque l'accès public est activé, les objets peuvent être exposés par l'intermédiaire d'un serveur r2.dev sous-domaine. Cloudflare indique également que les listes de seaux racine ne sont pas disponibles sur les seaux publics. Il s'agit d'un détail sous-estimé. L'impossibilité de lister un bucket ne sert à rien si un autre artefact donne déjà le chemin exact de l'objet. La sécurité par l'obscurité s'effondre dès qu'une carte des sources, un manifeste de construction ou une trace d'erreur donne à un attaquant l'URL complète. (Docs Cloudflare)

C'est la raison pour laquelle l'expression "une simple fuite de carte source" est trop décontractée. L'exposition d'une carte est souvent un événement de contrôle de la distribution. La question pertinente n'est pas de savoir si une .carte existait quelque part pendant la construction. La question pertinente est de savoir si la chaîne d'approvisionnement publique finale a permis à cette carte, ou à un pointeur public derrière elle, de survivre dans un canal accessible aux personnes extérieures. En pratique, cela signifie qu'il faut examiner l'archive, la copie du CDN, les règles du magasin d'objets, les valeurs par défaut du script de construction et l'étape de vérification postérieure à la publication. (Sentry Docs)

L'aspect npm est important car les écosystèmes de paquets publics amplifient rapidement les erreurs. La documentation actuelle d'Anthropic et le README officiel de GitHub indiquent maintenant que l'installation de npm est dépréciée et recommandent les méthodes d'installation natives à la place, tout en continuant à documenter npm pour les cas de compatibilité. Cela ne prouve pas que la dépréciation ait eu lieu à cause de cet incident, et il serait irresponsable de le prétendre. Mais cela signifie que les défenseurs devraient immédiatement séparer les déploiements de Claude Code basés sur npm des installations natives pendant le triage, parce qu'ils suivent des chemins de distribution différents et des attentes différentes en matière d'artefacts. (Docs de l'API Claude)

Pourquoi la fuite de la carte des sources de Claude Code est plus importante que la carte des sources d'un frontend classique ?

Claude Code n'est pas un paquet ornemental. L'aperçu d'Anthropic le décrit comme un outil de codage agentique qui lit des bases de code, édite des fichiers, exécute des commandes et s'intègre à des outils de développement à travers des surfaces de terminal, d'IDE, d'ordinateur de bureau et de navigateur. Il s'agit déjà d'une catégorie de sécurité différente de celle d'un ensemble de sites statiques ou d'un widget de tableau de bord. Si les détails de la mise en œuvre d'un tel outil deviennent plus faciles à lire, le prix n'est pas seulement une meilleure mise en évidence de la syntaxe pour les développeurs curieux. Il s'agit d'une carte plus claire des limites de confiance, des décisions de permission, des flux d'orchestration et des surfaces d'intégration. (Claude)

La documentation de sécurité d'Anthropic renforce ce point. Claude Code utilise par défaut des permissions strictes en lecture seule, demande l'approbation pour des actions supplémentaires, et inclut le modèle bash en bac à sable, des restrictions de portée d'écriture, et des mesures d'atténuation de l'injection d'invite. Le modèle de bash en bac à sable utilise spécifiquement l'isolation du système de fichiers et du réseau, et la documentation d'Anthropic sur les permissions indique que les restrictions de bac à sable peuvent empêcher les commandes bash d'atteindre des ressources en dehors des limites définies, même si l'injection d'invite influence la prise de décision de Claude. Un événement d'exposition à la source impliquant un runtime comme celui-ci n'a pas pour seul but d'apprendre à quoi ressemble l'interface utilisateur. Il s'agit de réduire le coût de l'analyse de la manière dont ces protections sont réellement assemblées. (Claude)

La surface télécommandée rend le propos encore plus incisif. Anthropic documente le contrôle à distance comme un moyen de poursuivre une session locale de Claude Code à partir d'un autre navigateur ou d'un autre appareil. La documentation est explicite sur le fait que la session s'exécute toujours sur la machine de l'utilisateur, que le processus local ne fait que des requêtes HTTPS sortantes et que la connexion utilise des informations d'identification à courte durée de vie. Il s'agit là d'une bonne information sur la conception de la sécurité, et non d'une preuve de l'existence d'une faille. Mais c'est aussi le genre de sous-système où les détails de l'implémentation ont une valeur stratégique pour quiconque essaie de comprendre l'état de la session, les limites de l'authentification et le courtage d'actions dans un agent d'exécution complexe. (Claude)

Anthropic intègre désormais des fonctions de vérification automatisée de la sécurité à l'intérieur de Claude Code, notamment /security-review et la révision basée sur les actions GitHub. Cela signifie que Claude Code n'est pas seulement un assistant de codage dans l'abstrait. Il fait de plus en plus partie des flux de travail réels des développeurs en matière de sécurité. Une divulgation de source impliquant ce type d'outil a donc un effet de second ordre : elle peut influencer la manière dont les développeurs évaluent la fiabilité de l'outil qu'ils utilisent pour inspecter d'autres logiciels. Les outils de sécurité font l'objet d'un examen plus approfondi parce que les conditions économiques sont différentes. Les chercheurs n'ont pas besoin d'un exploit direct dès le premier jour pour qu'une fuite comme celle-ci ait de l'importance. Ils ont besoin d'un meilleur point de départ. (Centre d'aide Claude)

Voici une façon pratique d'envisager les enjeux.

Capacité du code Claude	Ce que les documents officiels révèlent déjà	Pourquoi l'exposition à la mise en œuvre est-elle importante ?
Exécution de la commande	Bash est soumis à des autorisations et peut être placé dans un bac à sable.	Les chercheurs peuvent étudier l'application exacte et les cas limites
Repo trust et édition de fichiers	Lecture seule par défaut, écritures délimitées, modes de permission	Il est plus facile de raisonner sur les bogues et les erreurs de portée qui surviennent avant la mise en place du système de confiance
Télécommande	La session s'exécute localement, HTTPS sortant uniquement, crédits de courte durée.	L'orchestration des sessions et les transitions d'authentification deviennent moins coûteuses à analyser
Crochets, MCP, sous-processus	Claude peut s'intégrer à des outils et à des couches politiques	La propagation des secrets et les voies d'exécution indirectes deviennent plus visibles
Caractéristiques de l'examen de sécurité	/security-review et les actions GitHub sont prises en charge	La logique d'examen, les exclusions et les hypothèses deviennent plus faciles à tester.

Ce résumé ne prétend pas que la fuite publique a exposé tous ces éléments internes d'une manière exploitable. Il s'agit d'une déclaration sur les raisons pour lesquelles la perte de confidentialité autour d'un développeur agentique est plus conséquente que la perte de confidentialité autour d'un actif frontal normal. La documentation publique d'Anthropic divulgue déjà une partie significative du modèle ; une implémentation lisible abaisse la barrière restante. (Claude)

Anthropic publie déjà une partie du modèle de sécurité, ce qui rend la précision plus importante

Après une fuite, il est tentant de tout considérer comme secret et de tout considérer comme compromis. Ce n'est pas ainsi que fonctionne l'analyse de la sécurité d'un produit mature. Anthropic documente déjà publiquement une grande partie du modèle de sécurité de Claude Code : les modes de permission, le mode plan, le mode automatique, le sandboxing, le contrôle à distance, et les fonctionnalités d'examen de la sécurité. La documentation sur le mode automatique est particulièrement révélatrice de l'intention du concepteur. Ils indiquent qu'un classificateur distinct examine les actions dans leur contexte, que les résultats des outils sont retirés de l'entrée du classificateur et que la fonctionnalité est un aperçu de la recherche plutôt qu'une garantie de sécurité. Rien de tout cela n'est en soi une vulnérabilité. Mais cela montre qu'Anthropic voit le même problème que les défenseurs : les outils de codage agentique vivent ou meurent en fonction des limites de confiance et de la logique d'approbation. (Claude)

Cette divulgation publique va dans les deux sens. Du côté positif, cela signifie que les personnes extérieures n'ont pas besoin d'une fuite pour comprendre la philosophie générale de la conception. Du côté négatif, cela signifie que les questions restantes les plus intéressantes sont précisément les questions d'implémentation : dans quel ordre les vérifications sont-elles exécutées, où les exceptions sont-elles appliquées, quand la confiance est-elle établie, quels chemins sont autorisés avant une invite, qu'est-ce qui est hérité par les sous-processus, et comment les fallbacks se comportent-ils en cas de conditions de course ou d'entrée malformée. Ce sont exactement les questions qui deviennent plus faciles à explorer lorsque les sources deviennent lisibles. (Claude)

Ce que les preuves publiques ne prouvent pas

La discipline la plus importante dans un incident qui évolue rapidement est de dire ce que les preuves ne soutiennent pas. Les dépôts publics et les messages examinés dans le cadre de cet article soutiennent une allégation relative à la reconstitution des sources à partir d'artefacts de distribution de paquets. Ils ne démontrent pas, à eux seuls, le vol de référentiels de clients, de transcriptions de sessions ou d'invites d'utilisateurs. Le matériel mis en miroir publiquement après la fuite est décrit comme du code source, et non comme des données d'utilisateur. (GitHub)

L'avis sur la carte des sources d'Astro est une comparaison utile parce qu'il dit tout haut ce qui est silencieux. Dans ce cas, l'impact immédiat était l'exposition du code source, alors que les secrets ou les valeurs d'environnement n'étaient exposés que s'ils étaient présents textuellement dans le code source. L'avis indique également que le risque le plus grave en aval est ce qu'un attaquant peut découvrir une fois que le code devient visible. Ce cadre s'applique également ici. Un événement d'exposition du code source doit absolument être traité avec sérieux. Il ne faut pas pour autant le gonfler en affirmant que les preuves ne sont pas suffisantes. (GitHub)

La fonction de contrôle à distance est un autre domaine où la précision est importante. L'existence d'une interaction à distance avec Claude Code ne signifie pas que le produit ouvre des ports entrants sur les machines des développeurs. La documentation d'Anthropic indique que le processus local ne fait que des requêtes HTTPS sortantes et que les interfaces web ou mobiles agissent comme une fenêtre dans la session locale. Si quelqu'un prétend que la fuite de la carte des sources a révélé une porte dérobée exposée à l'internet dans chaque machine Claude Code, la documentation publique ne soutient pas cette affirmation. (Claude)

La classification actuelle est donc plus étroite et plus crédible : il semble s'agir d'un événement lié à la confidentialité des sources impliquant un outil de développement agentique de grande valeur. C'est suffisant pour justifier une réelle inquiétude. Ce n'est pas suffisant pour justifier une fiction. (GitHub)

Il convient d'ajouter une deuxième vérification de la réalité. Les pages publiques de navigation sur les paquets peuvent être décalées, différer ou omettre des détails, ce qui rend la reconstruction après coup difficile. Les miroirs du 31 mars indiquent qu'ils ont extrait les sources de cli.js.map dans le paquetage officiel. Version publique actuelle de jsDelivr browsing shows 2.1.88 et le principal cli.js mais pas un fichier cli.js.map dans la liste racine. C'est précisément pour cette raison que les rapports d'incidents doivent faire la distinction entre ce qui a été signalé comme étant accessible au moment de l'exposition et ce qu'un lecteur peut personnellement consulter quelques jours plus tard. C'est en confondant ces deux états que la rumeur remplace l'analyse. (GitHub)

Pourquoi les anciens CVE du code Claude sont-ils importants dans cette discussion ?

Si l'événement du 31 mars avait impliqué un outil passif sans antécédents de bogues limitant la confiance, l'histoire aurait encore de l'importance, mais il serait plus facile de la traiter comme une atteinte à la réputation d'abord et comme un problème de sécurité ensuite. Le code Claude ne correspond pas à cette description. Au cours de l'année écoulée, Anthropic et GitHub ont publié de nombreux avis concernant Claude Code dans des domaines directement liés aux invites de confiance, à l'exécution de commandes, à l'intégration d'IDE et à l'exfiltration de données. Ces problèmes ne sont pas les mêmes que ceux liés à la fuite de la carte des sources. Ils sont le contexte qui explique pourquoi les détails de mise en œuvre lisibles dans cette catégorie de produits sont stratégiquement utiles. (GitHub)

La tendance devient évidente lorsque les avis sont examinés côte à côte.

CVE	Ce qui s'est passé	Versions concernées et correctifs	Pourquoi c'est important ici
CVE-2025-52882	Les intégrations IDE ont accepté des connexions websocket d'origines arbitraires, permettant un accès non autorisé aux fichiers et à l'état de l'éditeur dans les environnements concernés.	>= 0.2.116, < 1.0.24fixé en 1.0.24	Montre comment les limites de confiance entre l'origine et l'IDE autour du code Claude ont déjà été un vrai problème.
CVE-2025-59828	La configuration de Yarn et les plugins pouvaient s'exécuter avant que l'utilisateur n'accepte la boîte de dialogue de confiance dans les répertoires	< 1.0.39fixé en 1.0.39	montre que l'ordre d'exécution préalable à la fiducie est une surface critique et historiquement fragile
CVE-2025-58764	Des failles dans l'analyse des commandes permettraient de contourner les messages d'approbation et de déclencher l'exécution de commandes non fiables dans un contexte hostile.	< 1.0.105fixé en 1.0.105	montre que la logique de validation des invites et des commandes est un objectif réaliste et non théorique
CVE-2025-64755	Un problème d'analyse sed permettait de contourner la validation en lecture seule et d'écrire des fichiers arbitraires sur l'hôte.	< 2.0.31fixé en 2.0.31	Montre que les garanties "en lecture seule" peuvent échouer aux limites de l'analyseur syntaxique et de l'application.
CVE-2026-21852	Claude Code pourrait émettre des requêtes API avant la confirmation de confiance et faire fuir des données, y compris les clés API d'Anthropic, via des paramètres repo malveillants.	< 2.0.65fixé en 2.0.65	montre que le flux de démarrage et de charge de projet avant la confirmation de la confiance est l'un des points les plus intéressants à étudier

C'est la raison principale pour laquelle l'exposition des sources est importante. Ces avis révèlent un thème récurrent : les bogues les plus conséquents du code Claude ne sont pas des bogues décoratifs. Ce sont des bogues qui se situent à la jonction entre l'intention de l'utilisateur, le contexte de l'invite, la confiance dans le référentiel, l'approbation de l'exécution, les origines de l'IDE et le comportement au démarrage. C'est exactement le type de logiciel pour lequel des sources lisibles réduisent fortement le coût de la recherche de cas particuliers. (GitHub)

Prenons l'exemple de CVE-2026-21852. L'avis de GitHub indique qu'un dépôt malveillant pourrait définir les paramètres suivants ANTHROPIC_BASE_URL afin que Claude Code effectue des requêtes avant d'afficher l'invite de confiance, ce qui pourrait entraîner une fuite des clés d'API. Il ne s'agit pas d'une vulnérabilité liée à la cartographie des sources. Il s'agit d'une vulnérabilité d'initialisation avant la confiance. Mais cela démontre pourquoi les développeurs se soucient de l'ordre exact de chargement des projets et de la synchronisation de l'invite de confiance dans ce produit. Une fois que ces surfaces sont connues comme étant de grande valeur, tout événement qui rend l'étude de l'implémentation moins coûteuse mérite l'attention. (GitHub)

CVE-2025-59828 aborde le même point sous un autre angle. Ce problème existait parce que le code lié à Yarn pouvait s'exécuter avant que la confiance dans les répertoires n'ait été acceptée. Encore une fois, la leçon intéressante n'est pas "Yarn est effrayant". La leçon intéressante est que le niveau de sécurité de Claude Code dépend des sous-systèmes qui s'exécutent avant ou après l'établissement de la confiance. Il s'agit là d'un cas classique où les détails d'implémentation importent plus que l'intention architecturale. (GitHub)

CVE-2025-58764 et CVE-2025-64755 passent de la confiance au démarrage à la confiance à l'exécution. L'un des avis indique qu'un contexte hostile pourrait contourner une invite d'approbation et déclencher l'exécution d'une commande non fiable. L'autre indique qu'une faille dans l'analyse sed pourrait contourner la validation en lecture seule et écrire des fichiers arbitraires. Ensemble, ils montrent que "approbation" et "lecture seule" ne sont pas des états magiques. Il s'agit de revendications politiques mises en œuvre par des codes d'analyse, de correspondance et d'application. Lorsque les sources deviennent plus lisibles, ces revendications politiques deviennent plus faciles à tester et à remettre en question. (GitHub)

CVE-2025-52882 est important pour une raison similaire du côté de l'IDE. L'avis de GitHub indique que les intégrations VS Code et JetBrains affectées permettaient des connexions websocket non autorisées à partir d'origines arbitraires et pouvaient exposer l'état des fichiers et des éditeurs. Ce problème provient d'une surface différente de celle de l'archive CLI. Il doit néanmoins être pris en compte car il montre que Claude Code fait partie d'une famille de produits multi-surfaces plus large où la gestion des origines, le routage des messages et les limites de session sont tous des éléments importants pour la sécurité. Un événement d'exposition de source affectant le CLI ne casse pas automatiquement l'IDE. Il rend la famille de produits plus transparente pour la recherche externe. (GitHub)

Les sessions locales de CLI, les sessions de contrôle à distance et les sessions web ne constituent pas la même surface de menace.

De nombreuses analyses publiques de la fuite regroupent tous les modes de déploiement de Claude Code en un seul bloc. Cela ne fait qu'empirer l'analyse. La documentation d'Anthropic établit une véritable frontière entre le Claude Code local, le Remote Control et le Claude Code sur le web. Le Claude Code local s'exécute sur la machine de l'utilisateur. Le contrôle à distance maintient l'exécution sur la machine de l'utilisateur et utilise l'interface web ou mobile comme surface de contrôle. Claude Code on the web, en revanche, s'exécute dans une infrastructure en nuage gérée par Anthropic. Il ne s'agit pas du même modèle de confiance ni de la même trace de preuve. (Claude)

Cette distinction est importante car l'impact de l'incident dépend de l'endroit où l'implémentation exposée s'applique réellement. Un problème de packaging dans une CLI distribuée par npm affecte principalement le chemin utilisé par les clients locaux installés par npm. Cela n'implique pas automatiquement que la même chaîne d'artefacts existe dans l'environnement web hébergé dans le nuage d'Anthropic. Inversement, un problème lié à l'environnement cloud n'aurait pas automatiquement d'incidence sur ce qui est présent dans un tarball npm local. Une gestion mature des incidents commence par tracer ces limites de déploiement avant de commencer à prédire le rayon d'action. (Docs de l'API Claude)

La même nuance s'applique aux hypothèses de confiance concernant le comportement du réseau. La documentation d'Anthropic sur l'utilisation des données indique que Claude Code local envoie des messages et des résultats de modèles sur le réseau aux services d'Anthropic. Cela signifie qu'il y a toujours une composante de service à distance dans l'expérience du produit. Mais la documentation indique également que les sessions de contrôle à distance suivent le flux de données local parce que l'exécution a lieu sur la machine où la session a été lancée. En d'autres termes, l'exposition des sources de l'exécution locale n'est pas automatiquement la même chose que la compromission de l'exécution dans le nuage, et la compromission de l'exécution dans le nuage n'est pas nécessaire pour qu'un événement de confidentialité de l'exécution locale ait de l'importance. (Claude)

À quoi ressemble une réaction grave d'un défenseur dans les premières 24 heures ?

La première erreur opérationnelle que commettent la plupart des équipes après un incident de ce type est d'essayer de répondre à l'internet avant de répondre à leur propre inventaire d'actifs. Commencez par les questions ennuyeuses. Où est installé Claude Code dans votre environnement. Quels sont les chemins d'installation utilisés ? Quelles sont les versions présentes. Quels sont les développeurs ou les CI runners qui utilisent encore le chemin npm déprécié. La documentation d'installation d'Anthropic et le repo officiel de GitHub indiquent tous deux que l'installation npm est dépréciée et recommandent les chemins d'installation natifs en premier, avec Homebrew et WinGet également documentés. Cela fait des installations basées sur npm la première partition évidente de tout plan de réponse. (Docs de l'API Claude)

La deuxième erreur est de limiter la recherche aux ordinateurs portables des développeurs. Les outils de codage agentique se retrouvent souvent dans des endroits que les développeurs oublient de mentionner : les runners CI auto-hébergés, les images GitHub Actions, les devcontainers, les hôtes de saut partagés, les stations de travail cloud jetables et les images dorées internes. Si votre organisation a normalisé "juste npm installer globalement", vous devez supposer qu'une copie existe quelque part où vous n'avez pas fait l'inventaire manuellement. Les miroirs de paquets publics affichent toujours 2.1.88 en tant que version présente dans l'écosystème, de sorte que "nous l'avons retiré d'un chemin" n'est pas un modèle mental suffisant pour le cycle de vie de l'exposition. (jsDelivr)

Un inventaire pratique de premier passage pourrait ressembler à ceci.

# Version locale et chemin d'accès
claude --version
qui claude

# Vérifier si l'installation de npm est obsolète
npm ls -g @anthropic-ai/claude-code --depth=0

# Vérifier les gestionnaires de paquets alternatifs
brew list --versions claude-code
winget list Anthropic.ClaudeCode

Documents explicitement anthropiques claude --versionLe but n'est donc pas d'inventer un nouveau flux de travail, mais de transformer les conseils d'installation officiels en une routine d'inventaire qui identifie le chemin de distribution que chaque machine utilise réellement. Il s'agit de transformer les conseils d'installation officiels en une routine d'inventaire qui identifie le chemin de distribution utilisé par chaque machine. (Docs de l'API Claude)

La troisième question ne concerne pas du tout l'emballage. Il s'agit d'une question de confiance. Les membres de votre équipe ont-ils l'habitude de diriger Claude Code vers des dépôts, des modules d'extension ou des artefacts générés qui ne sont pas fiables ? Si la réponse est oui, l'histoire de la carte des sources devrait déclencher une révision plus large du renforcement de Claude Code, parce que le risque historique réel du produit a souvent vécu aux limites de la pré-confiance et de la promptitude. La leçon à tirer de CVE-2026-21852, CVE-2025-59828, CVE-2025-58764 et CVE-2025-64755 n'est pas "paniquez maintenant". Il s'agit de "ne pas maintenir une posture d'exécution laxiste simplement parce que les gros titres d'aujourd'hui concernaient la divulgation de sources plutôt qu'une compromission directe". (GitHub)

La quatrième question concerne le degré d'autonomie que vous accordez actuellement. La documentation d'Anthropic sur le mode de permission est particulièrement utile à cet égard, car elle ne cache pas les compromis. plan est une planification en lecture seule. par défaut demande avant d'agir en dehors des travaux en lecture seule. automobile utilise un classificateur et est explicitement décrit comme un aperçu de la recherche plutôt que comme une garantie de sécurité complète. Permissions de contournement désactive les contrôles d'autorisation et n'est documentée comme appropriée que dans des environnements isolés tels que des conteneurs ou des machines virtuelles sans accès à l'internet. Cela signifie que le triage des incidents devrait inclure un examen des autorisations, et pas seulement un examen de la version du paquet. (Claude)

Si vos équipes explorent des référentiels inconnus en bénéficiant d'une large autonomie, un simple changement à court terme a une valeur disproportionnée : déplacez le travail d'inspection initial dans le référentiel plan ou le mode par défaut, maintenir le sandboxing activé, et réserver le mode Permissions de contournement pour les environnements réellement isolés. La documentation d'Anthropic sur le sandboxing indique que l'outil bash sandboxé utilise un système de fichiers et une isolation réseau au niveau du système d'exploitation, tandis que la documentation sur la sécurité indique que le sandboxing et les règles de refus permettent de limiter les dommages même si l'injection rapide influence les décisions de Claude. C'est le genre d'étape de renforcement qui reste importante même si l'événement du 31 mars s'avère avoir déjà été entièrement corrigé. (Claude)

Un autre gain rapide est l'hygiène des références autour des sous-processus. L'approche d'Anthropic v2.1.83 lancement introduit CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1qui supprime les informations d'identification d'Anthropic et du fournisseur de cloud des environnements de sous-processus tels que Bash, hooks et les serveurs stdio de MCP. Cette note de version est importante car elle reconnaît une vérité opérationnelle réelle : même lorsque l'agent principal est sous contrôle, l'héritage des sous-processus peut élargir le rayon d'action d'un bogue ou d'un flux de travail malveillant. Si vous utilisez Claude Code dans des environnements sensibles, ce paramètre mérite une attention particulière. (GitHub)

La politique de contrôle à distance mérite également d'être revue. Anthropic indique que le contrôle à distance est disponible sur tous les plans, mais qu'il est désactivé par défaut pour Team et Enterprise jusqu'à ce qu'un administrateur l'active. Si votre organisation n'en a pas besoin, le fait de le désactiver élimine une surface supplémentaire de l'exposition quotidienne. Si vous en avez besoin, rendez la politique explicite et documentez où les sessions locales sont autorisées à s'exécuter, car le contrôle à distance interagit avec le système de fichiers local de l'utilisateur et les outils locaux par conception. (Claude)

Une chose que les défenseurs ne devraient pas faire est de faire pivoter toutes les références en vue sur la base de la théorie selon laquelle "la fuite de la source prouve que les clés ont été volées". Les preuves publiques ne vont pas dans ce sens. La rotation des clés API Anthropic, des jetons OAuth ou des informations d'identification dans le nuage est basée sur des voies d'exposition concrètes. Par exemple, si vous avez exécuté des tests pré2.0.65 Claude Code dans des dépôts hostiles, CVE-2026-21852 crée un réel problème d'exfiltration de clés. Ce n'est pas le cas des rapports sur les cartes des sources du 31 mars. Le mélange de ces deux modèles produit un théâtre coûteux au lieu d'une réponse ciblée. (GitHub)

Comment inspecter l'artefact au lieu de se disputer à son sujet ?

La réponse la plus saine à un incident de conditionnement n'est pas la spéculation sans fin sur les captures d'écran. C'est l'inspection des artefacts. Si votre environnement s'appuie encore sur npm-distributed Claude Code pour une raison quelconque, ou si vous voulez appliquer la même discipline à vos propres paquets, inspectez l'archive réelle. Recherchez les cartes des sources, les URLs de débogage publiques, et les sourceMappingURL dans l'artefact final distribué, et pas seulement dans le référentiel ou le dossier de construction. C'est le seul contrôle qui corresponde à ce que les utilisateurs et les attaquants reçoivent. (Sentry Docs)

Un modèle de vérification locale sûre se présente comme suit.

TMPDIR="$(mktemp -d)"
cd "$TMPDIR"

# Tirez la version exacte du paquet que vous voulez inspecter
npm pack @anthropic-ai/claude-code@2.1.88

# Inspecter le contenu du paquet sans l'installer globalement
tar -tf ./*.tgz | grep -E '\.map$|cli\.js$'

# Extraire et rechercher des directives de mappage ou des URL de débogage publiques
tar -xzf ./*.tgz
grep -R -n 'sourceMappingURL' package 2>/dev/null
grep -R -n 'r2.dev\|src.zip' paquet 2>/dev/null

Ce flux de travail n'attaque rien. Il applique simplement l'hygiène de la chaîne d'approvisionnement des paquets à un artefact public. Vous pouvez utiliser la même méthode pour vos propres paquets internes avant la publication, pour les paquets tiers miroirs pendant la révision, ou pour les versions avec incident que votre organisation a encore en cache. La valeur de sécurité provient de la vérification de l'élément exact qui a franchi la limite de distribution. (OWASP)

La même logique s'applique à l'IC pour vos propres produits.

set -euo pipefail

npm pack >/dev/null
PKG="$(ls *.tgz | head -n1)"
WORKDIR="$(mktemp -d)"
tar -xzf "$PKG" -C "$WORKDIR"

if find "$WORKDIR/package" -type f | grep -E '\.map$' >/dev/null ; then
  echo "Build failed : sourcemap artifact found in package" (Échec de la construction : artefact de carte source trouvé dans le paquet)
  exit 1
fi

if grep -R -n 'sourceMappingURL\|r2.dev\|src.zip' "$WORKDIR/package" >/dev/null 2>&1 ; then
  echo "Build failed : debug pointer or public artifact URL found" (Échec de la construction : pointeur de débogage ou URL publique de l'artefact trouvée)
  exit 1
fi

L'objectif n'est pas d'interdire l'existence des cartes sources. Le but est de les rendre intentionnelles. Les documents de Sentry sont un bon modèle ici : téléchargez-les en privé lorsque vous en avez besoin, ou autorisez l'accès si vous devez les héberger. Ne laissez pas la question à l'appréciation du dernier bundler par défaut. (Sentry Docs)

Comment durcir le code Claude après cet incident

La réponse de l'emballage n'est qu'une couche. La posture d'exécution a plus d'importance au fil du temps. Les documents de sécurité d'Anthropic indiquent que Claude Code est en lecture seule par défaut et demande une approbation explicite pour les actions plus risquées. La documentation sur le mode de permission indique que plan est conçu pour l'analyse en lecture seule avant édition, tandis que le mode automobile réduit les messages par le biais d'un classificateur et Permissions de contournement désactive les contrôles dans les environnements isolés uniquement. Une base de durcissement raisonnable pour la plupart des équipes est simple : utilisez plan ou le mode par défaut pour les dépôts inconnus, activer le sandboxing pour tous les flux de travail qui peuvent le tolérer, et limiter fortement les cas où les utilisateurs peuvent s'exécuter sans contrôle. (Claude)

La documentation d'Anthropic soulève également un point important à propos de l'injection rapide. La page de sécurité indique que Claude Code inclut des protections contre l'injection rapide, et la documentation sur les permissions indique que les restrictions du bac à sable peuvent empêcher l'accès à bash en dehors des limites définies, même si la prise de décision de Claude est influencée. Cela signifie que le produit est déjà conçu autour de l'hypothèse que le jugement du modèle seul est insuffisant. Les défenseurs devraient adopter la même hypothèse. Ne vous fiez pas au fait que "le modèle comprendra probablement ce qui est sûr". Utiliser le bac à sable, les règles de refus et la séparation de l'environnement pour rendre les chemins dangereux non viables, même lorsque le modèle est orienté. (Claude)

La documentation sur le mode de permission est plus franche que celle de la plupart des fournisseurs en ce qui concerne automobile. Anthropic indique qu'il s'agit d'un aperçu de recherche, qu'il ajoute des allers-retours du classificateur et qu'il ne garantit pas la sécurité. La documentation précise également ce que le classificateur bloque par défaut, notamment le téléchargement et l'exécution de code, l'envoi de données sensibles à des points d'extrémité externes, les actions de contrôle de source destructives et les opérations ayant un impact sur la production. C'est utile, mais cela signifie aussi que les défenseurs doivent traiter les données de l automobile comme un mode de commodité contraint, et non comme une excuse pour relâcher les contrôles environnants. Si un flux de travail est suffisamment sensible pour qu'un humain soit mécontent d'approuver une fois la mauvaise action, il est suffisamment sensible pour mériter un examen explicite et des limites étroites. (Claude)

Les équipes qui s'appuient sur l'extensibilité de Claude Code doivent être particulièrement prudentes avec les crochets, les plugins, les serveurs MCP et les sous-processus. Ce sont des multiplicateurs de force lorsqu'ils sont contrôlés et des multiplicateurs d'explosion lorsqu'ils sont négligés. La note de version d'Anthropic introduit CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 est un rappel que les secrets peuvent se propager à travers les processus de soutien même lorsque la session de haut niveau semble contrôlée. Si votre environnement accorde à Claude Code l'accès à des dépôts internes, à des API dans le nuage ou à des connecteurs MCP privilégiés, vérifiez où ces informations d'identification circulent après que le processus principal a engendré des assistants. (GitHub)

Pour les équipes de sécurité autorisées, un modèle de compromis utile est l'utilisation de preuves d'abord. Laissez Claude Code raisonner sur les chemins de code, les bords de configuration et les conditions préalables suspectes. Il ne faut pas que ce raisonnement devienne le dernier mot en matière d'exploitabilité. Anthropic dit lui-même que les examens de sécurité automatisés devraient compléter, et non remplacer, les pratiques de sécurité existantes et les examens manuels. Il s'agit là d'un défaut sain pour cette catégorie d'outils en général. (Centre d'aide Claude)

Ce que les éditeurs de paquets devraient changer après avoir lu ce document

La principale leçon à tirer pour les éditeurs de paquets n'est pas "ne divulguez pas les cartes des sources". C'est trop superficiel pour survivre au contact d'un véritable pipeline de publication. La vraie leçon est que les artefacts de débogage ont besoin de leur propre cycle de vie et de leur propre modèle d'accès. La documentation de Sentry indique déjà la bonne architecture : télécharger les cartes de sources en privé vers le backend d'observabilité lorsque c'est possible, ou utiliser un accès protégé si l'hébergement public est inévitable. C'est en les traitant comme un simple actif statique que l'on crée ces classes d'échec évitables. (Sentry Docs)

Le stockage d'objets mérite la même discipline. La documentation R2 de Cloudflare indique que l'accès public n'est jamais activé par défaut et que r2.dev est une URL publique de développement destinée à des cas d'utilisation hors production. Ce langage devrait déjà sonner comme un avertissement à tous ceux qui stockent des artefacts liés à une version. Si votre organisation place des archives de débogage, des paquets de symboles ou des produits de construction transitoires dans le stockage d'objets, l'hypothèse la plus sûre est qu'un point de terminaison de développement public n'est pas le bon endroit pour eux. Le fait que le listing de la racine du seau ne soit pas disponible ne rend pas l'exposition des objets sûre si un autre artefact peut divulguer la clé exacte. (Docs Cloudflare)

L'autre leçon d'ingénierie est que l'inspection post-construction doit se faire sur le paquet final, et non sur l'arbre des sources. Les équipes ont souvent des linters qui interdisent les secrets dans les dépôts et des tâches CI qui analysent les images Docker. Beaucoup moins d'équipes inspectent l'arbre d'objets exacts (tarball, zip, CDN-uploaded) que les utilisateurs consomment. L'incident Claude Code, tout comme l'avis sur la carte des sources Astro avant lui, nous rappelle que l'artefact public peut s'écarter du modèle mental du développeur de manière subtile. Un paquet peut être "propre" en termes de repo et toujours fournir un chemin de divulgation une fois que la construction, le téléchargement et la mise en miroir sont terminés. (GitHub)

Un contrôle minimal côté web vaut toujours la peine d'être utilisé lorsque le modèle de déploiement le prend en charge. Si votre serveur web public ne doit jamais servir de .carte le dire explicitement.

location ~* \.(js|css)\.map$ {
    retour 403 ;
}

Ce n'est pas une stratégie complète. Elle ne vous sauvera pas si votre gestionnaire de paquets, votre CDN ou votre magasin d'objets expose les artefacts ailleurs. Elle ferme toujours un mode d'échec facile. Et si votre organisation a besoin de cartes de source pour le débogage, les conseils de Sentry donnent un meilleur modèle que "laissez-les publiques et espérez que personne ne le remarque". (Sentry Docs)

La dernière leçon de l'éditeur est d'ordre culturel. Les équipes doivent cesser de considérer la divulgation de sources comme inoffensive dès lors qu'"il n'y a pas de secrets dans les sources". L'avis d'Astro indique explicitement que l'impact immédiat peut être limité au code source, mais que la source divulguée peut ensuite permettre de découvrir d'autres vulnérabilités. L'OWASP dit la même chose de manière plus générale dans son guide de test. Dans le cas d'un moteur d'exécution agentique, cet effet en aval n'est pas hypothétique. L'implémentation elle-même fait partie de la surface d'attaque. (GitHub)

Pourquoi les conclusions de la boîte blanche doivent-elles être prouvées par la boîte noire après une fuite comme celle-ci ?

La divulgation d'une source crée un flot de théories plausibles sur les bugs. Certaines de ces théories seront justes. Beaucoup seront fausses. D'autres ne s'appliqueront qu'à des versions plus anciennes, à des chemins de déploiement différents ou à des fonctionnalités désactivées. C'est pourquoi le travail de sécurité post-fuite a besoin d'une séparation nette entre le raisonnement boîte blanche et la preuve boîte noire. Les documents d'Anthropic sur la revue de sécurité automatisée font le même mouvement philosophique dans un langage plus doux : les fonctionnalités de revue de sécurité aident à trouver des problèmes, mais elles sont des compléments aux pratiques de sécurité plus larges, et non des substituts à celles-ci. (Centre d'aide Claude)

Cette distinction est également l'endroit le plus utile pour mentionner Penligent sans transformer cet article en une page de vente. Les documents de Penligent relatifs à Claude plaident constamment en faveur de flux de travail fondés sur des preuves : utiliser Claude Code pour raisonner sur le code, les limites de confiance et les chemins probables ; utiliser la validation externe pour déterminer si ces chemins sont atteignables et significatifs dans l'environnement déployé ; puis retester après la correction. C'est exactement la bonne attitude à adopter après un événement d'exposition des sources, car une base de code lisible génère plus d'hypothèses qu'une équipe ne devrait traiter comme des conclusions par défaut. (penligent.ai)

Dans la pratique, le flux de travail est simple. Une équipe de sécurité peut prendre un bord de permission suspecté, un défaut d'ordre de démarrage, ou un chemin d'invocation d'outil de la revue de boîte blanche et le transformer en un plan de retest contrôlé contre la mise en scène ou un autre environnement autorisé. Une plateforme construite autour de la validation répétable et de la capture de preuves, y compris Penligent, est utile ici non pas parce qu'elle rend la revue de code obsolète, mais parce qu'elle force l'argument à revenir sur l'accessibilité, le comportement observé, et la preuve reproductible. C'est la discipline qui empêche les équipes de transformer chaque fuite de détail d'implémentation en une critique fantôme. (penligent.ai)

L'inverse est également vrai. Un effet confirmé de boîte noire sans contexte de code est souvent plus lent à corriger proprement. C'est pourquoi la boucle boîte blanche-boîte noire est importante. Le code Claude peut aider à expliquer ce qu'une faille suspectée est censée faire. La validation externe permet de tester ce que le système déployé fait réellement. Le point de fusion entre ces deux éléments est l'endroit où le travail de sécurité utile se produit. (Centre d'aide Claude)

Ce qu'il faut voir maintenant

Les prochains signaux qui feront autorité ne viendront pas de captures d'écran repostées. Ils proviendront des notes de version d'Anthropic, des versions GitHub, des changements dans la distribution des paquets et de toute communication formelle sur les incidents que l'entreprise choisira de publier. Selon les sources officielles examinées ici, les notes de publication publiques indiquent toujours 2.1.88 comme la dernière version de Claude Code, et la documentation d'Anthropic ne présente toujours npm que comme un chemin de compatibilité déprécié. C'est là que les défenseurs devraient continuer à surveiller le suivi de l'emballage ou de la distribution. (Claude)

Il est également utile de surveiller les miroirs de paquets publics et vos propres caches internes. Les pages publiques de jsDelivr suivent toujours 2.1.88 comme une version dans l'écosystème. Même lorsqu'un fournisseur supprime ou modifie un chemin de distribution, la présence de miroirs et la persistance du cache local peuvent compliquer le nettoyage et la certitude médico-légale. Si votre équipe a besoin d'une réponse définitive, inspectez l'artefact exact que votre environnement a réellement stocké ou installé. (jsDelivr)

La leçon la plus profonde est plus importante que le code Claude. Les outils de développement agentiques ne sont pas des logiciels ordinaires du point de vue de l'examen de la sécurité. Ils se situent à la frontière entre le code, le shell, les identifiants, les API dans le nuage, l'orchestration à distance et la politique. Cela signifie que leurs artefacts de publication méritent le même sérieux que les moteurs d'exécution qu'ils enveloppent. Une fuite de carte source dans cette catégorie de logiciels n'est jamais qu'un embarras cosmétique. Elle nous rappelle que le pipeline de construction, le registre des paquets, le magasin d'objets et le modèle d'approbation font tous partie d'un seul et même système de sécurité. (Claude)

Pour en savoir plus

• Anthropique, Aperçu du code Claude (Claude)
• Anthropique, Claude Sécurité du code, sandboxing, permissions et modes de permission (Claude)
• Anthropique, Utilisation des données de la télécommande et du code Claude (Claude)
• Anthropique, Examens de sécurité automatisés dans le code Claude (Centre d'aide Claude)
• Anthropique, Notes de mise à jour du code Claude et versions GitHub, y compris v2.1.88 et v2.1.83 (Claude)
• Cloudflare, R2 public buckets et r2.dev URL de développement public (Docs Cloudflare)
• MDN, OWASP, et Sentry sur les cartes de sources, les fuites d'informations et la gestion privée des artefacts de débogage (MDN Web Docs)
• Avis GitHub pour Astro, divulgation des sources du serveur par le biais de cartes de sources (GitHub)
• Avis GitHub pour Claude Code, CVE-2025-52882, CVE-2025-59828, CVE-2025-58764, CVE-2025-64755, et CVE-2026-21852 (GitHub)
• Penligent, Claude AI pour Pentest Copilot, Construire un flux de travail basé sur les preuves avec Claude Code (penligent.ai)
• Penligent, Claude Code Security and Penligent, From White-Box Findings to Black-Box Proof (La sécurité du code Claude et la négligence, des conclusions de la boîte blanche à la preuve de la boîte noire) (penligent.ai)