Code Claude, CLAUDE.md, et injection SQL

Au début du mois d'avril 2026, Hackread a résumé une divulgation de LayerX avec un titre qui a fait mouche pour une bonne raison : Le code de Claude pourrait être manipulé par CLAUDE.md pour réaliser un processus d'injection SQL dans un laboratoire contrôlé. L'angle d'attaque était la démonstration de SQLi. L'histoire la plus importante est celle de la limite de confiance qui la sous-tend. Claude Code n'est pas un chatbot passif. Anthropic le documente comme un outil de codage agentique qui peut lire votre base de code, éditer des fichiers, exécuter des commandes et s'intégrer à des outils de développement. Anthropic documente également CLAUDE.md comme un fichier d'instructions persistant qui se charge dans le contexte au fil des sessions. Mettez ces deux faits ensemble et le repo cesse d'être un simple code source. Il devient en partie une invite, en partie une politique, en partie une surface de contrôle des outils. (hackread.com)

Ce changement est plus important que l'expression "injection SQL" dans le titre. SQLi est familier. Ce qui est nouveau, c'est le chemin par lequel un fichier de dépôt peut influencer un agent de codage utilisant un outil qui a accès à un shell, à un répertoire de travail, à des chemins de réseau optionnels et à des systèmes externes optionnels par l'intermédiaire de MCP. La démonstration de DVWA contrôlé de LayerX est une étude de cas pertinente parce qu'elle montre que le modèle traite le texte à l'intérieur d'une base de données. CLAUDE.md en tant que contexte d'autorisation, puis de reporter ce contexte dans la sélection des actions pratiques. Les documents d'Anthropic indiquent que l'injection rapide n'est pas un problème résolu, en particulier lorsque les modèles prennent davantage d'actions dans le monde réel. Le rapport de LayerX montre à quoi ressemble cet avertissement une fois qu'il atteint le poste de travail d'un développeur. (LayerX)

Il ne s'agit pas de dire que Claude Code est uniquement imprudent ou que chaque version qui l'utilise est automatiquement dangereuse. La documentation d'Anthropic décrit une architecture basée sur les permissions, des valeurs par défaut en lecture seule, l'approbation des commandes, le sandboxing, la vérification de la confiance, les hooks et les paramètres gérés. Le fait est que ces contrôles n'ont de sens que si les équipes identifient correctement la surface sensible. Beaucoup d'équipes examinent déjà les Fichier Docker, package.jsonet les flux de travail de CI en tant qu'infrastructure exécutable. Moins d'équipes examinent CLAUDE.md, .claude/settings.json, .claude/rules/*.mdou .mcp.json avec la même rigueur. Dans un environnement de codage agentique, cette lacune n'a plus rien d'académique. (Claude)

Le code Claude ne se limite pas au chat avec accès au shell

La description du produit d'Anthropic est plus précise que le raccourci populaire autour de "AI coding assistant". Claude Code est un outil de codage agentique. La documentation indique qu'il lit votre base de code, édite des fichiers, exécute des commandes et s'intègre à des outils de développement. La documentation "comment ça marche" va plus loin et précise le contexte de travail : vos fichiers de projet, votre terminal, votre état git, et votre CLAUDE.md. La documentation MCP va encore plus loin en permettant à Claude Code de se connecter à des outils, des bases de données et des API par l'intermédiaire de serveurs Model Context Protocol. Il s'agit d'une surface opérationnelle plus large qu'un onglet de chat du navigateur, et c'est le bon point de départ pour comprendre pourquoi un fichier d'instructions local peut devenir un problème de sécurité. (Claude)

Un chatbot web ordinaire peut donner de mauvais conseils. Un agent de codage peut faire plus que cela. Il peut assembler le contexte à partir d'un repo, décider de la prochaine action, invoquer un outil de fichier, invoquer une commande shell, et potentiellement toucher un service connecté. La documentation de sécurité d'Anthropic reflète cette différence. Elle décrit des permissions strictes en lecture seule par défaut, des approbations explicites pour des actions supplémentaires, un bash en bac à sable avec isolation du système de fichiers et du réseau, une vérification de confiance pour les premières exécutions de la base de code et les nouveaux serveurs MCP, et des listes de blocage de commandes pour les outils de récupération de réseau à risque tels que boucler et wget par défaut. Aucune de ces commandes n'existerait si Claude Code n'était qu'un générateur de texte. Elles existent parce que le produit est un système d'action. (Claude)

Cette distinction explique également pourquoi "l'ingénierie inoffensive" et "l'état du référentiel sensible à la sécurité" peuvent se confondre dans le même problème. La documentation d'Anthropic encourage les développeurs à utiliser CLAUDE.md pour les instructions de projet persistantes. Ils prennent également en charge les importations, le chargement d'instructions imbriquées, les règles, les crochets, les paramètres et la configuration MCP qui cohabitent avec le code. Lorsque la mémoire du modèle et les outils du modèle se rencontrent dans le même arbre de travail, le texte n'est plus seulement narratif. Le texte fait partie de la gouvernance de l'exécution. (Claude)

Le tableau ci-dessous illustre la différence pratique entre une surface de discussion générale et un programme d'exécution de codage agentique. Il ne s'agit pas d'un tableau de comparaison de produits. Il s'agit d'un tableau sur les limites de la confiance.

Domaine de compétence	Assistant de chat typique	Claude Code runtime
Connaissance du référentiel	Seulement ce que l'utilisateur colle	Lecture directe de repo, connaissance de git, contexte de répertoire de travail
Instructions persistantes pour les projets	Contexte de conversation généralement temporaire	CLAUDE.mdrègles, mémoire locale, fichiers importés
Modification de fichier	Aucune par défaut	Outils d'édition et d'écriture intégrés, et sous-processus Bash
Exécution de la commande	Aucun	Outil Bash avec approbations, sandboxing optionnel
Systèmes externes	Généralement aucun	Serveurs MCP, outils CLI, WebFetch, flux de travail connectés à un navigateur
Question de confiance	La réponse est-elle correcte ?	Le repo, la configuration, le chemin d'accès à l'outil et la politique d'exécution sont-ils dignes de confiance ?

C'est la documentation d'Anthropic qui rend ce cadrage nécessaire. Plus le code Claude est autorisé à faire, plus la question de la sécurité passe de "Peut-on tromper le modèle en lui faisant dire quelque chose de mal" à "Qu'est-ce que le runtime traite comme un input de confiance lorsqu'il décide des actions à entreprendre". (Claude)

Comment CLAUDE.md fonctionne-t-il vraiment ?

CLAUDE.md est facile à comprendre parce qu'il ressemble à du markdown. La documentation d'Anthropic le décrit de manière plus fonctionnelle : un fichier d'instructions persistant qui transporte le contexte spécifique du projet à travers les sessions de Claude Code. La documentation sur la mémoire indique que chaque session commence avec une nouvelle fenêtre de contexte et que CLAUDE.md est l'un des mécanismes qui transmet les connaissances d'une session à l'autre. Les documents précisent également que ces fichiers sont chargés dans leur intégralité, même si des fichiers plus courts permettent généralement d'obtenir une meilleure adhésion. C'est important. Un fichier chargé à chaque session n'est pas une note destinée aux futurs humains. Il s'agit d'une instruction donnée à l'agent. (Claude)

Le modèle de chargement est plus large que ne le pensent de nombreuses équipes. Anthropic documente que Claude Code remonte l'arbre des répertoires à partir du répertoire de travail actuel et charge les éléments suivants CLAUDE.md et CLAUDE.local.md qu'il trouve. Les fichiers découverts sont concaténés dans le contexte plutôt que de se substituer les uns aux autres. Dans le même répertoire, CLAUDE.local.md est ajouté après CLAUDE.md. Les fichiers dans les sous-répertoires peuvent également être récupérés paresseusement lorsque Claude lit les fichiers dans ces emplacements. Pour une grande mono-répo ou un arbre d'ingénierie partagé, cela signifie que la surface d'instruction peut changer en fonction de l'endroit où l'agent opère. Cela est puissant pour les flux de travail légitimes et dangereux lorsque personne ne suit ce qui est réellement chargé. (Claude)

Le modèle d'importation étend à nouveau la surface. Les documents de mémoire d'Anthropic disent CLAUDE.md peut importer des fichiers supplémentaires avec @chemin/vers/import et les fichiers importés sont développés et chargés dans leur contexte au lancement, les importations récursives étant prises en charge jusqu'à cinq sauts. Cette fonctionnalité est utile pour les aperçus de projets, les guides de flux de travail ou les règles d'équipe partagées. Elle rappelle également que la limite de sécurité n'est pas le seul fichier visible sur lequel un réviseur clique pour l'ouvrir. Un petit fichier d'apparence inoffensive CLAUDE.md peut toujours tirer davantage de matériel d'instruction d'autres parties du répertoire ou même de chemins absolus approuvés par l'utilisateur. (Claude)

Les .claude formalise le reste de la surface de comportement. La documentation du répertoire d'Anthropic indique que Claude Code lit les instructions, les paramètres, les compétences, les sous-agents, les règles, les crochets, la configuration MCP et la mémoire à partir du répertoire du projet et de ~/.claude. Le tableau de référence des fichiers énumère explicitement CLAUDE.md, les règles, settings.jsonIl s'agit là d'une leçon architecturale plus profonde dans toute cette histoire. C'est la leçon architecturale la plus profonde de toute cette histoire. Dans un outil de codage agentique moderne, le repo n'est pas seulement du code. C'est du code plus de la configuration d'exécution plus de la mémoire plus de la politique plus de l'intégration d'outils. (Claude)

Le tableau suivant est un meilleur modèle mental pour les défenseurs que "il y a un fichier markdown bizarre que je devrais peut-être regarder".

Fichier ou répertoire	Ce qu'il fait	Pourquoi il est important pour la sécurité
CLAUDE.md	Chargement des instructions à chaque session	Peut façonner le cadre de la tâche, les hypothèses d'autorisation et le comportement à l'égard des outils
CLAUDE.local.md	Projet personnel - dérogations locales	Peut modifier silencieusement le comportement d'un opérateur ou d'un arbre de travail.
.claude/rules/*.md	Instructions à portée de sujet ou de chemin	Peut injecter du contexte lorsque des fichiers spécifiques sont touchés
.claude/settings.json	Permissions, hooks, env vars, model defaults	Peut modifier le comportement d'approbation et les contraintes d'exécution
.mcp.json	Serveurs MCP partagés en équipe	Peut étendre les systèmes auxquels Claude peut accéder
.claude/hooks/	Automatisation de l'exécution et logique de la politique	Peut autoriser, refuser, différer ou contrôler l'utilisation de l'outil
~/.claude/projets/.../mémoire/	Mémoire automatique pour le projet	Possibilité de maintenir les hypothèses opérationnelles d'une session à l'autre
~/.claude/projets/.../*.jsonl	Transcriptions complètes	Peut capturer le contenu de fichiers sensibles, la sortie de commandes et les secrets collés.

Cette dernière ligne mérite plus d'attention qu'elle n'en reçoit. Anthropic documente le fait que les transcriptions et l'historique sont en clair sur le disque et ne sont pas chiffrés au repos. Si un outil lit un fichier secret ou si une commande imprime un identifiant, cette valeur peut se retrouver dans les transcriptions de session. Cela ne crée pas de contournement de LayerX, mais augmente le rayon d'action lorsqu'une session fonctionne déjà dans un contexte pollué. (Claude)

Ce que LayerX a montré et ce qu'il n'a pas montré

Le document public de LayerX est très précis sur le mécanisme de base. Le message indique que les invites du système dans Claude Code sont gérées par le biais de CLAUDE.mdLe fichier se trouve dans le dépôt de code et toute personne disposant d'une autorisation d'écriture peut le modifier pour l'ensemble d'un projet. Dans la démonstration contrôlée, les chercheurs ont utilisé DVWA, placé trois courtes lignes d'autorisation dans le fichier CLAUDE.mdIl a ensuite demandé à Claude Code de l'aider à contourner une connexion et à vider la base de données des mots de passe. LayerX affirme que Claude a explicitement cité CLAUDE.md comme base d'autorisation pour la tâche et a procédé à une séquence comprenant de multiples tentatives de charge utile SQLi, des requêtes cURL, le réglage de la sécurité DVWA à un niveau faible, la découverte de la base de données actuelle, l'énumération des tables et l'extraction des noms d'utilisateur et des hachages de mots de passe. (LayerX)

L'article de Hackread condense tout cela dans un récit médiatique, mais le résumé est cohérent avec l'article de LayerX. L'article de Hackread indique que les règles de sécurité de Claude Code ont été contournées par le biais de CLAUDE.mdL'attaque a été démontrée dans un environnement contrôlé à l'aide d'une application vulnérable, et le modèle a traité le fichier texte comme base de travail. Pour les lecteurs techniques, l'important n'est pas qu'un média ait parlé d'"injection SQL". Ce qui est important, c'est que le résumé des médias a correctement identifié le mécanisme comme un problème de confiance. CLAUDE.mdet non comme une affirmation selon laquelle Anthropic dispose d'un mode SQLi intégré. (hackread.com)

LayerX a également défini le risque de manière plus large qu'une simple démonstration de SQLi. L'article présente trois vecteurs : test de pénétration et exfiltration de données, dépôt public malveillant et menace interne. Ce cadre est plus fort que le titre, car il indique clairement que l'objet dangereux n'est pas une chaîne de données utiles spécifique. Il s'agit de la combinaison d'un canal d'instructions de confiance et d'un moteur d'exécution capable d'agir. Un dépôt public malveillant est particulièrement important car les développeurs clonent régulièrement du code qu'ils n'ont pas écrit. Dans un modèle mental normal de développeur, il s'agit d'un problème de chaîne d'approvisionnement si le dépôt contient des scripts shell dangereux, des dépendances ou des configurations CI. L'idée de LayerX est que la couche d'instruction elle-même peut faire partie de cette même chaîne d'approvisionnement. (LayerX)

Ce que la divulgation n'a pas montré est tout aussi important. Elle ne prétendait pas que le code Claude pouvait toujours contourner tous les contrôles de sécurité. Elle ne prétendait pas que n'importe quelle cible arbitraire sur l'internet public peut être compromise sans interaction de l'utilisateur. Il ne s'agissait pas d'un exploit complet contre l'infrastructure d'Anthropic. Il s'agissait d'une démonstration contrôlée qu'un fichier d'instructions résidant dans un répertoire peut être traité comme un contexte d'autorisation fiable suffisamment fort pour pousser le modèle vers un comportement nuisible dans un environnement d'utilisation d'outils. C'est déjà grave. Il n'est pas nécessaire de l'exagérer. (LayerX)

Il y a également une nuance concernant la divulgation des fournisseurs qui mérite d'être soulignée. LayerX dit avoir soumis le problème à Anthropic par l'intermédiaire de HackerOne et avoir été redirigé vers un autre canal de signalement pour des problèmes de sécurité des modèles. Les documents publics d'Anthropic font état à la fois d'un programme de primes de sécurité des modèles lié à HackerOne et d'un programme distinct de primes de sécurité des modèles. usersafety@anthropic.com le chemin de signalement des problèmes de sécurité du système actuel et des problèmes de type "jailbreak". En d'autres termes, la voie de signalement des résultats "sécurité des modèles et jailbreak" n'est pas identique à la voie de signalement des vulnérabilités logicielles classiques. Cette distinction est logique d'un point de vue opérationnel, mais elle illustre également la raison pour laquelle cette catégorie de problèmes se situe maladroitement entre la sécurité des applications, la sécurité des produits et la sécurité des modèles. (LayerX)

Pourquoi l'injection SQL est-elle apparue dans la démo ?

L'injection SQL n'est pas la partie la plus profonde de l'histoire de LayerX, mais elle n'est pas non plus accidentelle. SQLi est un véhicule de démonstration propre à l'utilisation abusive de l'agent parce qu'il est procédural, testable et facile à raconter. Il donne au modèle une tâche offensive reconnaissable avec des étapes intermédiaires évidentes : trouver la surface de connexion, essayer des contournements, inspecter le contexte de la base de données, énumérer les tables et extraire les informations d'identification. Un chercheur peut montrer chaque étape par des captures d'écran sans avoir à publier un logiciel malveillant complet ou une chaîne d'exploitation fragile à plusieurs hôtes. Cette technique est donc bonne pour la divulgation et pour les gros titres. (LayerX)

Plus important encore, SQLi met en évidence la distinction entre l'explication et l'exécution. Tout LLM compétent peut parler de l'injection SQL dans l'abstrait. Claude Code est différent parce que l'exécution peut passer de la discussion à l'action assistée par le shell. La documentation d'Anthropic indique que l'outil peut exécuter des commandes, et LayerX indique que la démo a utilisé des requêtes cURL que Claude a générées et tenté d'exécuter après les avoir traitées CLAUDE.md en tant qu'autorisation de projet. C'est à cette étape que les équipes de sécurité doivent s'intéresser : lorsqu'un fichier d'instructions, une invite et l'accès à un outil deviennent une véritable boucle d'action. (Claude)

Il n'est pas nécessaire de reproduire les commandes ou les charges utiles de LayerX pour comprendre les implications opérationnelles. La leçon est générale. Tout flux de travail offensif qui peut être décomposé en "énoncer l'autorisation, générer l'étape suivante, exécuter par le biais d'outils autorisés, inspecter le résultat, continuer" devient plus plausible une fois que le modèle fait confiance au texte du repo comme source légitime d'autorisation. SQLi s'est avéré être le chemin de démonstration. Le problème de l'architecture est beaucoup plus vaste. (LayerX)

La véritable cause profonde est une décision de confiance, pas une astuce rapide

La version restreinte de cette histoire est "l'injection d'une invite dans un fichier markdown". La version la plus exacte est "un système capable d'agir se fie à une entrée non fiable pour prendre des décisions relatives à la sécurité". Cette formulation est importante car elle correspond à la fois à l'ingénierie logicielle et à l'historique des CVE dans le code Claude lui-même. La documentation d'Anthropic dit CLAUDE.md fournit des instructions persistantes. LayerX a montré que le modèle pouvait traiter ces instructions comme un contexte d'autorisation. Une fois qu'un système utilise un texte contrôlé par le repo pour aider à décider si des actions nuisibles sont autorisées, le problème est plus important qu'une manipulation stylistique de l'invite. Il s'agit d'un bogue du modèle de confiance. (Claude)

Les documents de sécurité d'Anthropic soutiennent ce point de vue. Les documents précisent que l'injection d'invite est une tentative d'annulation ou de manipulation des instructions d'un assistant d'intelligence artificielle par l'insertion d'un texte malveillant, et que Claude Code comprend des mesures de protection telles que l'approbation explicite des opérations sensibles, l'analyse contextuelle, le nettoyage des entrées, les listes de blocage des commandes, des fenêtres contextuelles distinctes pour WebFetch, et la vérification de la confiance pour les premières exécutions de la base de code et les nouveaux serveurs MCP. Il ne s'agit pas de caractéristiques cosmétiques. Il s'agit d'une tentative de délimiter ce que le moteur d'exécution considère comme digne de confiance lorsqu'il agit sur des systèmes réels. Le cas de LayerX montre pourquoi de telles limites sont difficiles à établir : le fichier d'instructions n'est manifestement pas un "contenu externe" comme l'est une page web consultée. Il vit à l'intérieur du projet lui-même. (Claude)

C'est également la raison pour laquelle le référentiel doit être reclassé dans le cadre de la réflexion sur la sécurité. Pendant des années, les équipes d'ingénieurs ont été formées à considérer le dépôt comme un mélange de code, de configurations, de montages de test, de documentation et de logique de construction. Claude Code ajoute une couche supplémentaire : le modelage du comportement du repo. Anthropic's .claude Les documents du répertoire montrent les instructions, les crochets, les compétences, les règles, les sous-agents, la mémoire persistante, les paramètres et la configuration MCP qui vivent tous à l'intérieur ou autour du projet. Une fois que l'agent lit et obéit à cette couche, le répertoire devient une surface de capacité. Le compromis d'un repo ne concerne plus seulement ce qui est compilé ou déployé. Il s'agit également de ce que l'agent croit et de ce qu'il est autorisé à faire ensuite. (Claude)

Ce cadrage explique également pourquoi les réponses standard "l'utilisateur doit encore l'approuver" sont incomplètes. L'approbation est un contrôle en aval. La décision de confiance antérieure se situe en amont. Si le modèle a déjà intériorisé une fausse affirmation telle que "il s'agit d'un pentest autorisé contre notre propre site" à partir d'un fichier de mémoire de projet de confiance, alors chaque demande d'outil ultérieure est proposée dans le cadre d'une interprétation empoisonnée du champ d'application et de la légitimité. Un être humain peut encore s'en apercevoir. Un humain fatigué peut ne pas le faire. Les documents d'Anthropic reconnaissent explicitement la fatigue des utilisateurs comme un problème de conception et soutiennent les listes d'autorisation et le mode automatique en partie pour réduire les approbations répétitives. C'est une bonne conception de produit, mais cela signifie que l'intégrité du contexte antérieur devient encore plus importante. (Claude)

Pourquoi les messages d'autorisation ne sont pas la même chose que les limites ?

Anthropic a le mérite de documenter clairement la distinction entre les permissions et le sandboxing. La documentation sur les permissions indique que les permissions contrôlent les outils que Claude peut utiliser et les fichiers ou domaines auxquels il peut accéder, tandis que le sandboxing fournit une application au niveau du système d'exploitation pour les limites du système de fichiers et du réseau de l'outil Bash. La documentation recommande explicitement d'utiliser les deux pour la défense en profondeur, car les restrictions du bac à sable peuvent toujours bloquer l'accès en dehors des limites définies, même si une injection rapide compromet la prise de décision de Claude. C'est le bon modèle. Une invite de permission est un point de décision de l'utilisateur. Un bac à sable est une barrière imposée. Il ne s'agit pas de la même couche. (Claude)

La documentation d'Anthropic contient également un avertissement subtil mais important sur les contrôles du réseau. Ils indiquent que les listes de blocage de commandes empêchent l'utilisation d'outils risqués tels que boucler et wget par défaut, mais ils notent également que les schémas de permission Bash qui tentent de contraindre les arguments de commande sont fragiles. La documentation sur les permissions donne des exemples concrets montrant comment le filtrage d'URL basé sur la correspondance des motifs du shell peut échouer en raison d'une réorganisation des arguments, de redirections, de l'utilisation de variables ou de changements de protocole. La même page recommande de refuser les outils réseau génériques et d'autoriser à la place WebFetch pour les domaines approuvés. Il prévient également que l'utilisation de WebFetch seul n'empêche pas l'accès au réseau si Bash est toujours autorisé. C'est l'une des notes de sécurité les plus utiles de l'ensemble de la documentation de Claude Code. (Claude)

Un autre malentendu courant concerne le blocage de la lecture des fichiers. La documentation d'Anthropic dit Lire Les règles de refus s'appliquent aux outils de fichiers intégrés, mais pas aux sous-processus Bash. Une règle de refus bloquant Lire(.env) ne s'arrête pas cat .env si l'accès Bash est autorisé. Anthropic recommande dans ce cas le sandboxing pour une application au niveau du système d'exploitation. C'est important parce que la plupart des scénarios cauchemardesques que les gens imaginent autour du codage agentique impliquent exactement ce schéma : le modèle décide de lire des secrets ou des fichiers de configuration par des commandes shell plutôt que par l'outil de lecture intégré. Si une équipe suppose que les règles de déni constituent en elles-mêmes une barrière infranchissable, elle fait une mauvaise lecture de l'architecture. (Claude)

Le mode automatique ajoute une autre couche de nuance. La documentation du mode automatique d'Anthropic indique qu'un classificateur distinct peut examiner les actions, maintenir une liste fixe d'outils sûrs et ne bloquer que ce qui semble risqué. La documentation sur les modes de permission indique que le mode automatique suit toujours un ordre de décision fixe et se replie lorsque le classificateur bloque de manière répétée. C'est utile pour la productivité et peut réduire les clics inutiles. Il ne s'agit pas d'un remplacement pour l'hygiène du repo, l'examen du fichier d'instructions ou la configuration du bac à sable. Un classificateur ne peut juger une action qu'une fois que le système a déjà cadré la tâche qu'il pense être en train d'accomplir. Si la couche d'instructions locales est trompeuse, le classificateur opère en aval de ce cadrage. (anthropic.com)

Il en va de même pour les modes "bypass permissions". La documentation du bureau d'Anthropic indique que le mode "bypass-permissions" est équivalent à --dangerously-skip-permissions et ne doit être utilisé que dans des conteneurs ou des machines virtuelles en bac à sable. Les administrateurs d'entreprise peuvent le désactiver. Cet avertissement doit être lu littéralement. Si un repo, un helper ou une mauvaise habitude opérationnelle place l'agent dans un mode d'exécution permissif sans isolation externe forte, les protections restantes sont plus minces que ne le pensent de nombreux utilisateurs. (Claude)

La surface d'attaque de Repo est plus grande qu'un fichier Markdown

Une fois que vous avez cessé de traiter CLAUDE.md comme une histoire complète, il devient plus facile de raisonner sur une surface d'attaque plus large. L'approche d'Anthropic .claude Les documents de l'annuaire répertorient non seulement des instructions, mais aussi des paramètres, des crochets, des compétences, des règles, des sous-agents, des serveurs MCP, des mémoires persistantes et des transcriptions locales. Chacune d'entre elles élargit ce qu'un référentiel contrôlé par un attaquant ou un compte de coéquipier compromis peut influencer. CLAUDE.md est important parce qu'il est le plus visible. .claude/settings.json est important parce qu'il peut influencer le comportement des permissionnaires et les crochets. .mcp.json est important car il permet d'étendre les systèmes externes avec lesquels Claude peut communiquer. Les règles sont importantes parce qu'elles peuvent être chargées conditionnellement lorsque le modèle lit certains chemins. Les crochets sont importants parce qu'ils peuvent directement autoriser, refuser, modifier ou différer l'exécution d'un outil. (Claude)

Les crochets sont particulièrement importants car Anthropic les documente comme des commandes shell, des points de terminaison HTTP ou des invites LLM qui s'exécutent automatiquement à des moments précis du cycle de vie. Les PreToolUse Le crochet peut autoriser, refuser, demander ou différer l'appel d'un outil et peut même modifier l'entrée de l'outil avant son exécution. Le crochet ConfigChange permet de bloquer l'entrée en vigueur des modifications de configuration pendant une session en cours. Le crochet InstructionsLoaded se déclenche lorsque CLAUDE.md ou les règles sont chargées, bien qu'Anthropic note que cette étape est asynchrone et ne supporte pas le blocage. En termes pratiques, cela signifie que les défenseurs peuvent intégrer l'observabilité et l'application de la politique dans Claude Code, mais ils doivent comprendre quelle étape du cycle de vie a réellement des dents. InstructionsLoaded est excellent pour l'exploitation forestière. PreToolUse et ConfigChange sont le point de départ de l'application de la législation. (Claude)

MCP élargit encore le rayon d'action. La documentation MCP d'Anthropic indique que Claude Code peut se connecter à des centaines d'outils et de sources de données externes, et la documentation sur la sécurité indique qu'Anthropic ne gère pas et n'audite pas les serveurs MCP. La documentation encourage l'écriture de vos propres serveurs ou l'utilisation de serveurs de fournisseurs en qui vous avez confiance. Il s'agit là d'un avertissement judicieux. C'est aussi un signal fort que les sources de données connectées font maintenant partie de la surface d'attaque. Un contexte d'instruction pollué plus un serveur MCP sur-privilégié est une combinaison beaucoup plus dangereuse qu'un contexte d'instruction pollué seul. (Docs de l'API Claude)

Et puis il y a les résidus de données. La documentation du répertoire d'Anthropic indique que tout ce qui passe par un outil peut aboutir à des transcriptions en clair sur le disque, y compris le contenu des fichiers, la sortie des commandes et le texte collé. La documentation précise même qu'en mode non-interactif, --non-session-persistance peut être utilisé avec -p d'éviter de rédiger des transcriptions. C'est le genre de détail opérationnel qui compte dans les environnements réels. Une session compromise ou manipulée ne se termine pas lorsque l'agent cesse de fonctionner. Elle peut laisser derrière elle des artefacts durables qui contiennent exactement les secrets que l'attaquant voulait que l'agent touche. (Claude)

Chaîne d'approvisionnement, menaces d'initiés et risques non interactifs

Les trois scénarios de LayerX méritent d'être traités comme une taxonomie de la chaîne d'approvisionnement plutôt que comme une divulgation unique. Le premier cas est celui du dépôt malveillant public. Un développeur clone du code, lance Claude Code et hérite d'instructions dont il n'est pas l'auteur et qu'il ne reverra peut-être jamais. La documentation d'Anthropic propose une vérification de la confiance pour les premiers codes, mais la question de confiance ne fonctionne que si l'utilisateur comprend ce qu'on lui demande de faire. Beaucoup de développeurs lisent ce dialogue comme "est-ce que je fais confiance au code de ce repo pour qu'il vaille la peine de travailler dessus", et non pas "est-ce que je fais confiance aux instructions, à la politique et aux surfaces d'intégration externes qui vont façonner le comportement de mon agent". L'article de LayerX expose exactement ce décalage. (LayerX)

Le deuxième cas est celui de l'initié ou de l'identité compromise. LayerX mentionne explicitement les employés mécontents, les comptes compromis ou les entrepreneurs malveillants qui modifient une identité existante. CLAUDE.md. Dans de nombreuses équipes d'ingénieurs, ce changement ne déclencherait pas la même urgence d'examen qu'un changement dans les scripts de construction, les outils secrets ou les flux de déploiement. La documentation d'Anthropic indique clairement que cela devrait être le cas. CLAUDE.md est chargé à chaque session, et des paramètres ou des crochets peuvent modifier ce que l'agent est autorisé à faire. Un attaquant n'a pas besoin de cacher un script shell s'il peut cacher un canal d'instructions de confiance. (LayerX)

Le troisième cas est l'utilisation non interactive. La documentation d'Anthropic sur la sécurité indique que la vérification de confiance est désactivée en mode non-interactif avec l'option -p drapeau. C'est compréhensible du point de vue du flux de travail, mais cela modifie la posture de sécurité. L'humain qui aurait pu remarquer un fichier d'instructions étrange ou un repo suspect n'est plus dans la boucle au début de la session. Si ce flux non interactif est également associé à des paramètres permissifs, à des règles d'autorisation larges ou à des informations d'identification de grande valeur dans l'environnement, la marge d'erreur se réduit très rapidement. La documentation d'Anthropic propose des solutions défensives, notamment dontAskLes paramètres gérés, le sandboxing, et les --non-session-persistancemais les équipes doivent les transformer en politique plutôt que de les laisser comme des notes de bas de page facultatives. (Claude)

La piste CVE montre qu'il s'agit d'un problème de classe de produits

Le LayerX CLAUDE.md L'histoire devient beaucoup plus facile à situer lorsque l'on examine la piste publique des CVE du code Claude entre la fin de 2025 et 2026. Il ne s'agit pas toujours du même bogue. Il s'agit d'une carte des endroits où la confiance est rompue dans un temps d'exécution de codage agentique : avant les dialogues de confiance, dans la résolution des permissions, dans l'analyse des commandes, dans le comportement de chargement du projet et dans l'exécution de l'aide. Lues ensemble, elles révèlent un schéma cohérent. Le défi n'est pas seulement de "prévenir les logiciels malveillants" ou de "bloquer un exploit". Il s'agit de concevoir un moteur d'exécution capable d'agir utilement tout en prenant des décisions de confiance correctes concernant les référentiels, les paramètres, les invites et les limites des commandes. (nvd.nist.gov)

Un point de départ utile est CVE-2025-59536. NVD indique que les versions antérieures à la version 1.0.111 étaient vulnérables à l'injection de code en raison d'un bogue dans l'implémentation du dialogue de confiance au démarrage, permettant à Claude Code d'exécuter le code contenu dans un projet avant que l'utilisateur n'ait accepté le dialogue de confiance. La signification est simple : le moment de la "première ouverture" est critique pour la sécurité. Si le contenu d'un projet peut influencer l'exécution avant que la confiance ne soit établie, le dialogue de confiance a déjà perdu une partie de son sens. Ce CVE est directement lié à la CLAUDE.md Le débat sur la divulgation de LayerX porte également sur ce qui se passe lorsque le matériel contrôlé par le repo est considéré comme digne de confiance plus tôt qu'il ne devrait l'être. (nvd.nist.gov)

Ensuite, il y a CVE-2026-21852NVD a déclaré qu'il s'agissait de l'un des cas les plus clairs de dépôt malveillant dans les archives publiques de Claude Code. Selon NVD, les versions antérieures à la 2.0.65 permettaient à des dépôts malveillants d'exfiltrer des données, y compris les clés API d'Anthropic, avant que les utilisateurs ne confirment leur confiance. Le mécanisme signalé était un dépôt contrôlé par l'attaquant qui configurait ANTHROPIC_BASE_URL à un point de terminaison de l'attaquant afin que Claude Code émette des requêtes avant d'afficher l'invite de confiance. Ce n'est pas la même chose que CLAUDE.mdmais il s'agit de la même leçon en matière de sécurité : l'état contrôlé par le référentiel influence les comportements sensibles avant que la confiance ne soit réellement établie. (nvd.nist.gov)

CVE-2026-33068 se rapproche encore plus du thème de la frontière de confiance. NVD indique que les versions antérieures à la 2.1.53 ont résolu le mode de permission à partir des fichiers de configuration, y compris le fichier .claude/settings.jsonavant de déterminer s'il convient d'afficher la boîte de dialogue de confirmation de la confiance dans l'espace de travail. Un référentiel malveillant pourrait définir permissions.defaultMode à Permissions de contournementce qui fait que la boîte de dialogue de confiance est ignorée lors de la première ouverture et que l'utilisateur est placé dans un mode permissif sans consentement explicite. Si vous vouliez un exemple de "dépendance à l'égard de données non fiables dans une décision de sécurité", vous n'auriez pas besoin d'en inventer un. La NVD classe déjà la faiblesse de cette manière. (nvd.nist.gov)

CVE-2025-54795 montre pourquoi "il y avait toujours une demande de confirmation" ne peut pas être considéré comme une réponse définitive. NVD indique que dans les versions inférieures à 1.0.20, une erreur dans l'analyse des commandes permettait de contourner la demande de confirmation du code Claude et de déclencher l'exécution d'une commande non fiable, étant donné la possibilité d'ajouter un contenu non fiable dans une fenêtre contextuelle du code Claude. La version du correctif est importante, mais la leçon architecturale l'est encore plus. Les invites, les dialogues et les approbations humaines ne sont pas des garanties stables si l'analyse du système et le modèle de confiance sont erronés en amont. (nvd.nist.gov)

CVE-2026-25723 ajoute un autre élément important. Selon NVD, les versions antérieures à la version 2.0.55 permettaient de contourner les restrictions d'écriture de fichiers par l'intermédiaire d'un fichier pipé. sédimentaire des opérations avec écho, ce qui permet d'écrire dans des répertoires sensibles tels que .claude et les chemins en dehors de la portée du projet lorsque l'option "accepter les modifications" a été activée. C'est très pertinent pour les CLAUDE.md et .claude La sécurité car elle signifie qu'un contexte hostile réussi ou un chemin d'outil n'est pas limité à la lecture de fichiers sensibles ou à la génération de commandes risquées. Dans certaines conditions, il peut également s'auto-renforcer en s'inscrivant dans la surface de la politique qui façonne le comportement futur de l'agent. (nvd.nist.gov)

Deux divulgations d'avril 2026 sur l'injection de commandes élargissent le tableau au-delà de la confiance dans les opérations de pension et dans les voies d'assistance. CVE-2026-35021 décrit l'injection de commandes du système d'exploitation dans l'utilitaire d'invocation de l'éditeur d'invite par le biais de chemins d'accès à des fichiers piratés, et CVE-2026-35022 décrit l'injection de commandes dans l'exécution de l'aide à l'authentification lorsque les valeurs de configuration de l'aide ont été exécutées avec la commande shell=truepermettant le vol d'informations d'identification et l'exfiltration de variables d'environnement. Il s'agit de bogues différents, mais ils indiquent la même vérité opérationnelle : une fois qu'un agent de codage accumule des éditeurs, des binaires d'aide, des wrappers de shell, des paramètres et des intégrations de fournisseurs, l'examen de la sécurité doit couvrir l'ensemble du tissu d'exécution, et pas seulement le modèle et le repo. (nvd.nist.gov)

Le tableau ci-dessous est le moyen le plus court de voir le modèle.

CVE	Ce qui a échoué	Pourquoi c'est important ici	Version corrigée ou état
CVE-2025-59536	Un bogue dans la boîte de dialogue de confiance au démarrage permettait l'exécution de code avant l'acceptation de la confiance	"Untrusted repo" est une limite d'exécution en direct, pas une formalité.	Corrigé dans la version 1.0.111 (nvd.nist.gov)
CVE-2026-21852	Les paramètres contrôlés par Repo pourraient exfiltrer les clés API avant la demande de confiance	Les dépôts malveillants peuvent abuser de la configuration avant que le consentement de l'utilisateur ne soit significatif	Corrigé dans la version 2.0.65 (nvd.nist.gov)
CVE-2026-33068	Contrôlé par repo .claude/settings.json pourrait fixer Permissions de contournement avant le dialogue de confiance	Les décisions en matière de sécurité ne doivent pas s'appuyer sur des données contrôlées par le repo avant que la confiance ne soit établie.	Corrigé dans la version 2.1.53 (nvd.nist.gov)
CVE-2025-54795	Contournement de l'invite de confirmation par une faille dans l'analyse des commandes	Les messages d'approbation ne sont pas des limites strictes	Corrigé dans la version 1.0.20 (nvd.nist.gov)
CVE-2026-25723	Contournement des restrictions à l'écriture de fichiers en .claude et en dehors du champ d'application du projet	La surface de contrôle de l'agent peut devenir accessible en écriture dans de mauvaises conditions.	Corrigé dans la version 2.0.55 (nvd.nist.gov)
CVE-2026-35021	Injection de commande OS dans l'invocation de l'éditeur d'invite	Les chemins d'exécution des assistants font partie de la surface d'attaque	Entrée publique de la NVD publiée le 6 avril 2026 (nvd.nist.gov)
CVE-2026-35022	Injection de commande OS dans l'exécution de l'aide à l'authentification	Les aides à l'identification peuvent devenir des voies d'exfiltration	Entrée publique de la NVD publiée le 6 avril 2026 (nvd.nist.gov)

Ce qu'il faut retenir, ce n'est pas "le code Claude est cassé de par sa conception", mais plutôt que cette catégorie de produits est difficile de par sa conception. C'est que cette catégorie de produits est difficile à concevoir. Elle doit décider à quoi faire confiance tout en agissant dans des environnements partiellement fiables. C'est exactement la catégorie de système où les bogues subtils de séquençage, la configuration contrôlée par le repo et les surprises du modèle de permission se transforment en véritables enregistrements de vulnérabilité. (nvd.nist.gov)

Un manuel de triage défensif pour les équipes réelles

Le moyen le plus rapide d'améliorer la sécurité est d'arrêter de se demander "Utilisons-nous Claude Code" et de commencer à se demander "Quelles sont les données d'entrée qui déterminent réellement le comportement de Claude Code dans ce répertoire". La première étape du triage est l'inventaire. Trouvez chaque CLAUDE.md, CLAUDE.local.md, .claude/rules/*.md, .claude/settings*.json, .mcp.jsonet le script hook dans le projet. La documentation d'Anthropic suggère également d'utiliser /mémoire, /contexte, /permissions, /hookset /mcp pour inspecter ce qui a été chargé dans la session en cours. Cela vous donne à la fois une vue statique de ce qui existe sur le disque et une vue d'exécution de ce que l'agent a réellement consommé. (Claude)

Un point de départ défensif pratique est un audit de la base de données locale qui traite les fichiers de contrôle de l'agent comme des artefacts sensibles :

find . \
  \( -name 'CLAUDE.md' -o -name 'CLAUDE.local.md' -o -name '.mcp.json' \) \
  -print

find ./.claude -type f \
  \( -name 'settings*.json' -o -path './.claude/rules/*.md' -o -path './.claude/hooks/*' \) \
  -print 2>/dev/null

rg -n \
  'bypassPermissions|ANTHROPIC_BASE_URL|apiKeyHelper|awsAuthRefresh|gcpAuthRefresh|curl|wget|@[^ ]+' \
  . .

Ce type d'analyse ne prouvera pas l'existence d'une intention malveillante, mais il mettra rapidement en évidence les endroits où le texte contrôlé par le repo peut influencer les autorisations, le routage du réseau, l'exécution des aides, les importations ou l'utilisation d'outils. Cela suffit à faire passer la discussion d'une vague préoccupation à un examen concret. La nécessité de ce type d'analyse découle directement de la documentation d'Anthropic sur la disposition des fichiers, le modèle d'importation, la surface de paramétrage et les CVEs liés aux aides. (Claude)

La deuxième étape est le contrôle des modifications. Placez ces fichiers sous CODEOWNERS ou des règles d'approbation équivalentes. La documentation d'Anthropic indique explicitement que les fichiers de projet dans .claude peut être transféré dans git et partagé par toute l'équipe. Le contrôle de version devient ainsi une frontière de sécurité, et pas seulement un outil de collaboration. Si un référentiel nécessite déjà une révision pour les flux de travail de CI, les définitions de conteneurs ou les configurations de déploiement, la même règle devrait s'appliquer à la gestion des versions. CLAUDE.md, les règles, les paramètres et les .mcp.json. (Claude)

La troisième étape est l'instrumentation de l'exécution. Le système de crochets d'Anthropic est suffisamment puissant pour appliquer une politique locale significative. ConfigChange peuvent empêcher les modifications de configuration de prendre effet dans une session en cours. PreToolUse Les crochets peuvent refuser ou différer les appels aux outils Bash, WebFetch, Read, Edit, Write, Agent et MCP. InstructionsLoaded Les crochets ne peuvent pas bloquer, mais ils peuvent toujours enregistrer et alerter chaque fois qu'un nouveau fichier d'instructions entre dans le contexte. Cela signifie qu'une équipe mature peut détecter "un fichier d'instructions imbriqué". CLAUDE.md vient d'être chargé parce que Claude s'est rendu dans un sous-répertoire" ou "une session vient d'essayer d'utiliser Bash selon un schéma suspect". (Claude)

Un crochet minimal Bash-deny pour bloquer les utilitaires réseau évidents et les écritures dans le répertoire de politique de l'agent pourrait ressembler à ceci :

#!/usr/bin/env bash
# .claude/hooks/pretool-guard.sh

INPUT="$(cat)"
TOOL_NAME="$(jq -r '.tool_name' <<<"$INPUT")"

if [ "$TOOL_NAME" = "Bash" ]; then
  CMD="$(jq -r '.tool_input.command // ""' <<<"$INPUT")"

  if echo "$CMD" | grep -Eq '(^|[[:space:]])(curl|wget)([[:space:]]|$)'; then
    jq -n '{
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision: "deny",
        permissionDecisionReason: "Direct network utilities are blocked. Use approved WebFetch domains or a reviewed wrapper."
      }
    }'
    exit 0
  fi

  if echo "$CMD" | grep -Eq '(^|[[:space:]])(cat|cp|mv|sed|tee).*(\.claude/|CLAUDE\.md|\.env)'; then
    jq -n '{
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision: "ask",
        permissionDecisionReason: "Sensitive policy or credential path. Manual review required."
      }
    }'
    exit 0
  fi
fi

exit 0

Il ne s'agit pas d'un moteur de politique universel. C'est un rappel que la surface d'accroche documentée d'Anthropic est suffisamment forte pour mettre en œuvre des contrôles locaux, et que ces contrôles doivent se concentrer sur les fichiers et les actions qui façonnent réellement le comportement de l'agent. (Claude)

Durcir le code de Claude sans prétendre que le risque est nul

L'erreur la plus difficile à corriger est d'ordre organisationnel et non technique. Les équipes doivent commencer à traiter les instructions de l'agent résident comme une gouvernance exécutable. Une fois ce changement opéré, le reste du chemin de renforcement devient plus clair.

Premièrement, renforcer l'hygiène du référentiel. Anthropic a déjà documenté l'existence d'une vérification de confiance pour les premières bases de code et les nouveaux serveurs MCP, mais elle documente également le fait que la vérification de confiance est désactivée dans les bases de code non interactives et les serveurs MCP. -p mode. Cela signifie qu'une politique devrait être simple : ne pas exécuter Claude Code de manière non interactive contre des dépôts non révisés, et ne pas supposer que le même point de contrôle humain existe dans l'automatisation que dans l'utilisation interactive locale. Pour l'IC ou d'autres flux non surveillés, appairer -p avec des autorisations verrouillées, un bac à sable strict, et --non-session-persistance dans la mesure du possible. (Claude)

Deuxièmement, appliquer le sandboxing comme une exigence, et non comme une commodité. La documentation d'Anthropic sur le sandboxing indique qu'un sandboxing efficace nécessite une isolation du système de fichiers et du réseau, et que sans isolation du réseau, un agent compromis pourrait exfiltrer des fichiers sensibles, tandis que sans isolation du système de fichiers, il pourrait créer une porte dérobée sur les ressources locales pour obtenir un accès au réseau. La documentation indique également que le bac à sable peut échouer à s'ouvrir par défaut si des dépendances sont manquantes, non prises en charge ou restreintes, sauf si sandbox.failIfUnavailable est fixé à vrai. Dans les environnements sensibles sur le plan de la sécurité, ce paramètre ne doit pas rester implicite. Si le bac à sable fait partie de la conception de la sécurité, le fait de ne pas le démarrer doit interrompre le travail, et non produire une bannière d'avertissement qui sera ignorée. (Claude)

Troisièmement, refuser par défaut l'utilisation d'outils réseau directs dans Bash. La documentation d'Anthropic sur les permissions est inhabituellement explicite à ce sujet : les règles d'URL de Bash basées sur des arguments sont fragiles, et les équipes devraient bloquer les règles de boucler, wgetet d'autres outils similaires, puis autoriser WebFetch(domaine :...) pour des domaines spécifiques. Les mêmes documents préviennent également que si Bash est autorisé, Claude peut toujours utiliser ces utilitaires pour atteindre des URL arbitraires, à moins que vous ne les refusiez ou que vous ne les contraigniez par le biais de sandboxing et de hooks. Il ne s'agit pas d'un cas particulier. Il s'agit d'une règle de conception de base pour tout environnement dans lequel l'agent peut rencontrer un contenu non fiable. (Claude)

Un exemple de paramétrage renforcé peut incarner cette règle :

{
  "permissions": {
    "deny": [
      "Bash(curl*)",
      "Bash(wget*)",
      "Read(./.env)",
      "Edit(.claude/**)",
      "Write(.claude/**)"
    ],
    "allow": [
      "WebFetch(domain:docs.anthropic.com)",
      "WebFetch(domain:code.claude.com)"
    ]
  },
  "sandbox": {
    "failIfUnavailable": true,
    "allowedDomains": [
      "docs.anthropic.com",
      "code.claude.com"
    ]
  },
  "defaultMode": "default"
}

Aucun extrait statique n'est complet, et les chemins précis doivent correspondre à votre environnement. L'important est la forme de la politique : réduire la couche réseau, protéger la surface de contrôle de l'agent, et échouer lorsque l'isolation n'est pas disponible. Les documents d'Anthropic soutiennent directement ces trois mouvements. (Claude)

Quatrièmement, contrôler la dérive de la configuration pendant les sessions. Anthropic's ConfigChange peut bloquer l'entrée en vigueur des modifications de configuration. Il ne s'agit pas seulement d'une fonction d'audit. Il peut s'agir d'un frein à la politique en vigueur. En pratique, une équipe peut refuser les tentatives de modification des modes de permission, d'ajout de crochets risqués ou de reconfiguration des paramètres une fois qu'une session a démarré. C'est particulièrement utile car certains des CVE historiques les plus risqués de Claude Code impliquaient des paramètres contrôlés par le repo influençant les décisions de sécurité trop tôt ou trop largement. (Claude)

Cinquièmement, restreindre les MCP de manière agressive. La documentation d'Anthropic indique que Claude Code peut se connecter à des centaines d'outils externes et qu'Anthropic ne gère ni n'audite les serveurs MCP. Il s'agit là d'une excellente raison de classer les points de terminaison MCP en fonction de leur sensibilité. La documentation et les outils de suivi des problèmes sont une chose. Les bases de données, les surfaces d'administration de production, les courtiers d'authentification dans le nuage ou les systèmes de secrets internes en sont une autre. Si Claude Code n'a pas besoin d'un accès direct côté cible pour un cas d'utilisation donné, ne lui donnez pas cet accès. Le moindre privilège est tout aussi important pour les outils d'agent que pour les comptes de service. (Docs de l'API Claude)

Sixièmement, gérer l'exposition des données locales. La documentation d'Anthropic indique que les transcriptions et l'historique sont en clair sur le disque et protégés uniquement par les autorisations du système d'exploitation. Ils précisent également que tout ce qui passe par un outil peut atterrir dans un fichier de transcription. Le résultat est simple : si votre utilisation de Claude Code touche des secrets, des données réglementées ou un contexte interne sensible, la politique de stockage local est importante. Réduisez les fenêtres de conservation. Envisagez des postes de travail dédiés ou des conteneurs. Utiliser --non-session-persistance lors d'exécutions sans surveillance. Ne supposez pas non plus qu'une session sécurisée reste sécurisée après sa sortie si le disque conserve tout ce que l'agent a vu. (Claude)

Une limite pratique, Raisonner n'est pas prouver

Les équipes commettent une deuxième erreur après avoir sous-estimé le risque côté repo : elles surestiment ce qu'un agent de codage peut prouver. Claude Code peut être très fort pour lire le code, tracer la logique d'authentification, cartographier les limites de confiance, réviser les correctifs, rédiger des contrôles de régression, et construire des boucles de validation locales. La documentation publique d'Anthropic soutient ce positionnement, et le produit est clairement conçu pour l'utilisation d'outils et le travail technique itératif. Mais une explication soignée de la part d'un agent de codage n'est pas la même chose qu'une démonstration de l'impact sur une cible réelle. (Claude)

Cette distinction est également importante dans cette histoire. La démonstration de LayerX est convaincante parce qu'elle passe du raisonnement à l'action dans un environnement contrôlé. La bonne réponse défensive n'est pas de "ne jamais utiliser d'agents de codage pour le travail de sécurité". Il s'agit de séparer le raisonnement de la boîte blanche de la preuve du côté de la cible. Claude Code est très utile du côté du raisonnement : réduction des hypothèses, formalisation des vérifications, examen des changements et compréhension du système local autour du code. Il est plus faible en tant que moteur de preuve final pour une exposition réelle, une exploitabilité réelle ou un rayon d'explosion réel, à moins qu'un vérificateur indépendant ne vérifie les affirmations. Les documents d'Anthropic sur l'injection rapide et la sécurité vont exactement dans ce sens en mettant l'accent sur les vérificateurs, les approbations et les actions limitées dans le monde réel. (anthropic.com)

C'est également là qu'une plateforme de pentest orientée vers le flux de travail entre naturellement en jeu, sans transformer la discussion en une page de vente. Les documents publics de Penligent positionnent la plateforme autour de l'exécution des tâches, de la vérification des résultats et de la production de rapports par rapport à des objectifs réels, et l'un de ses propres éléments de comparaison avec Claude Code présente la division comme un audit boîte blanche et une direction de correctifs d'un côté, contre une preuve boîte noire et une revérification de l'autre. Il s'agit là d'une division opérationnelle judicieuse. Utiliser un agent de codage lorsque l'accès au code, les outils locaux et le raisonnement sur les correctifs créent un effet de levier. Utilisez un flux de travail orienté vers la cible lorsque la question devient "Puis-je prouver que ceci est réel dans les conditions de déploiement actuelles et préserver les preuves ? (penligent.ai)

Ce que les équipes matures devraient changer ce trimestre

La version la plus simple de la réponse est la suivante : politique, examen et isolement.

Commencez par classer les fichiers suivants comme sensibles : CLAUDE.md, CLAUDE.local.md, .claude/settings*.json, .claude/rules/*.md, .mcp.jsonet tous les scripts de type "hook" ou "helper" que Claude Code peut invoquer. Placez-les derrière la propriété du code et l'examen des modifications. Examiner les importations. Examiner les chemins d'instructions imbriqués. Examiner les ajouts de MCP. Examiner les changements de mode de permission. Examiner toute configuration qui touche à l'exécution de l'assistant ou au routage du réseau. L'historique public des CVE montre déjà qu'il ne s'agit pas de fichiers décoratifs. Il s'agit d'intrants importants pour la sécurité. (Claude)

Verrouillez ensuite les paramètres par défaut de l'exécution. Refuser les outils réseau génériques dans Bash. Préférer WebFetch sur les domaines approuvés. Activez le sandboxing et configurez-le pour qu'il soit fermé en cas d'échec. Utiliser PreToolUse pour une application supplémentaire de la politique. Utiliser ConfigChange pour arrêter la dérive de la durée d'exécution. Désactiver ou limiter étroitement les modes de contournement des autorisations. Et traiter l'utilisation non interactive comme un niveau de confiance distinct avec des contrôles plus stricts, et non comme "la même chose mais automatisée". La documentation d'Anthropic fournit déjà les éléments de base. Le véritable travail consiste à les transformer en valeurs par défaut. (Claude)

Enfin, réapprendre le modèle mental. Le repo n'est plus passif. Dans un environnement de codage agentique, il peut contenir des instructions, des règles, des permissions, de la mémoire, des intégrations d'outils et une logique d'assistance qui affectent matériellement ce que l'agent voit et ce qu'il essaie de faire. Cela signifie que la confiance dans le référentiel est désormais en partie une confiance dans l'exécution, en partie une confiance dans la politique et en partie une confiance dans les données. Si les équipes continuent à examiner uniquement le code qui est livré à la production tout en ignorant les fichiers de gouvernance de l'agent qui façonnent l'action locale et automatisée, elles défendent la mauvaise frontière. (Claude)

La leçon principale

La divulgation de LayerX est mémorable parce qu'elle a utilisé l'injection SQL comme moyen de démonstration. La leçon durable est plus large. CLAUDE.md est un exemple visible de quelque chose de plus grand : la politique repo-native est devenue un contexte exécutable pour les outils de développement agentique. La documentation d'Anthropic montre à quel point ce contexte est puissant, depuis les instructions persistantes et les importations jusqu'aux paramètres, aux crochets, aux serveurs MCP et aux transcriptions locales. La liste publique des CVE montre à quel point les problèmes de sécurité dans cette catégorie de produits apparaissent souvent là où la confiance est établie, ignorée ou mal appliquée. La bonne réponse n'est ni la panique ni le déni. Il s'agit de traiter le repo comme une partie du runtime, et de le durcir en conséquence. (Claude)

Lectures complémentaires et références

Les documents officiels d'Anthropic sur le code Claude, la mémoire, la sécurité, les permissions, les crochets, le sandboxing, le MCP et le mode automatique sont les meilleures sources primaires pour savoir comment le produit est censé se comporter, quels fichiers façonnent le comportement et quels garde-fous existent dans le modèle documenté. (Claude)

La divulgation originale du "Vibe Hacking" de LayerX est la principale source publique pour le "Vibe Hacking". CLAUDE.md la démonstration du DVWA, les trois scénarios de menace, et la recommandation de traiter le CLAUDE.md comme un code exécutable. Le rapport de Hackread est utile en tant que résumé médiatique concis de la même recherche. (LayerX)

Les entrées NVD pour CVE-2025-59536, CVE-2026-21852, CVE-2026-33068, CVE-2025-54795, CVE-2026-25723, CVE-2026-35021, et CVE-2026-35022 sont les archives publiques les plus pertinentes pour comprendre comment la confiance dans le code Claude, les permissions, le comportement au démarrage, les limites des fichiers, et l'exécution des aides ont déjà produit de véritables divulgations de vulnérabilités. (nvd.nist.gov)

Les pages anglaises les plus pertinentes pour la lecture de Penligent sur ce sujet sont les suivantes Recherche sur le contournement de la sécurité du code Claude, Claude AI pour Pentest Copilot, Construire un flux de travail basé sur les preuves avec Claude Codeet 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). La page d'accueil de Penligent est la référence produit la plus large si vous avez besoin du contexte général du flux de travail après avoir lu ces documents. (penligent.ai)