Le dépôt ne devrait pas pouvoir voter sur sa propre confiance

Le 24 avril 2026, Anthropic a publié GHSA-q5hj-mxqh-vv77, un contournement de la boîte de dialogue de confiance Claude Code avec un score CVSS de 7,7. Trente-sept jours plus tôt, le 18 mars, le même projet publiait GHSA-mmgp-wc2j-qcv7 avec le même score CVSS. Deux contournements de la boîte de dialogue de confiance dans le même runtime d’agent et dans la même fenêtre de six semaines ne sont pas une coïncidence.¹²

La forme partagée constitue la leçon. Dans le bug de mars, le fichier .claude/settings.json contrôlé par le projet était lu avant la vérification de la confiance du workspace, et un mode de permission bypassPermissions dans ce fichier satisfaisait trivialement la barrière.² Dans le bug d’avril, un dépôt malveillant embarque un fichier commondir forgé à l’intérieur de .git/, l’évaluateur de confiance suit le pointeur vers un répertoire que l’utilisateur a déjà approuvé, et le workspace hérite de cette confiance sans jamais afficher la boîte de dialogue.¹

Deux lignes de texte à l’intérieur d’un dépôt que personne n’a encore ouvert pouvaient voter pour qu’un workspace soit approuvé. Les surfaces au niveau projet que le dépôt embarque (hooks, configurations de serveur MCP, skills, sous-agents) peuvent ensuite être résolues sur la base de ce vote, que ce soit avec empressement au démarrage de la session ou paresseusement lorsqu’elles sont invoquées. Les défenses en aval de tout runtime d’agent dépendent d’une décision que le runtime prend avant qu’elles n’existent.

TL;DR

• Deux CVE de contournement de la boîte de dialogue de confiance Claude Code en 37 jours montrent ce qui casse lorsque des octets contrôlés par le dépôt influencent la confiance du workspace.
• Le correctif immédiat côté utilisateur consiste à passer à une version postérieure à 2.1.84, à restreindre les chemins approuvés dans ~/.claude.json et à éviter la confiance sur des chemins parents larges comme ~/Projects.
• Le correctif structurel est un invariant d’ordre de chargement : n’interpréter aucun octet du workspace tant que le chemin du workspace n’est pas explicitement approuvé.

Ce que les deux avis ont réellement corrigé

La lecture des correctifs au regard de la documentation rend visible la défaillance d’ordre de chargement. Les versions corrigées réordonnent les octets que l’évaluateur de confiance est autorisé à consulter.

L’avis de mars décrit Claude Code résolvant les paramètres du projet avant de résoudre la confiance du workspace. Le correctif de la version 2.1.53 inverse cet ordre, de sorte que la vérification de confiance ne lit plus .claude/settings.json à l’intérieur du workspace avant que l’utilisateur n’ait décidé.² L’avis d’avril décrit l’évaluateur de confiance suivant le fichier commondir dans le répertoire .git/ d’un dépôt pendant la résolution du chemin du workspace lui-même. Le correctif de la version 2.1.84 empêche l’évaluateur d’honorer le contenu du commondir contrôlé par le dépôt pendant l’évaluation de la confiance.¹ Les deux correctifs rétablissent le même invariant : la décision de confiance ne doit pas consulter d’octets qui résident à l’intérieur du workspace candidat.

Les classifications CVE pointent vers le même diagnostic. Le bug de mars est classé CWE-807, Reliance on Untrusted Inputs in a Security Decision.³ Le bug d’avril est classé CWE-20 plus CWE-77, Improper Input Validation et Improper Neutralization of Special Elements, parce que la résolution du commondir traitait les octets contrôlés par le dépôt comme faisant autorité.¹ CWE différents, même supposition cassée : une barrière de sécurité qui lit depuis l’artefact qu’elle est censée protéger.

La surface pré-confiance est plus large que ne le laisse entendre la référence des paramètres

Claude Code documente un ensemble de surfaces de démarrage de session contrôlées par le projet qui doivent rester derrière la barrière de confiance. Les deux CVE de cette classe prouvent que l’invariant casse lorsque l’une d’entre elles entre dans la décision de confiance elle-même. Les surfaces se divisent en deux portées que l’analyse de confiance doit garder séparées : les octets qui voyagent avec un dépôt cloné, et les octets qu’un utilisateur ajoute à un workspace localement sans les commiter.⁴⁵⁶⁷

Surfaces commitées dans le dépôt (transportées par git clone). Ce sont les surfaces de la chaîne d’approvisionnement. Tout ce qui figure dans ce groupe est ce qu’un attaquant contrôle lorsqu’il rédige un dépôt malveillant.

Surfaces locales au workspace (non commitées par défaut). Celles-ci ne voyagent pas via la chaîne d’approvisionnement vers le workspace ; elles apparaissent lorsqu’un utilisateur local les crée. Elles résident toujours à l’intérieur du chemin du workspace, donc la barrière de confiance doit les traiter comme non approuvées tant que le chemin n’est pas validé.

Les hooks résident à l’intérieur de .claude/settings.json plutôt que dans un fichier séparé ; l’avis d’avril décrit l’attaquant peuplant directement cette clé.¹⁶ Le bug d’avril a également révélé une surface qui ne figure pas du tout dans la référence de configuration de Claude Code : un fichier interne à git nommé commondir, qui résout un worktree vers son dépôt parent.⁸ Un dépôt malveillant qui embarque une disposition commondir forgée hérite de la confiance du chemin cible lorsque Claude Code suit le pointeur pendant l’évaluation de la confiance. La surface interne à git a fait dérailler le décompte des surfaces de configuration de projet, et c’est la véritable leçon. La taxonomie n’est pas close. La surface d’attaque est définie par quels octets sont lus avant que la boîte de dialogue ne se déclenche, et tout ce qui peut influencer la résolution de chemin ou la configuration est de bonne guerre.

Le motif est celui que Les serveurs MCP sont la nouvelle surface d’attaque a nommé à une altitude différente.⁹ Les serveurs MCP ont fait exploser la surface des fournisseurs d’outils avant que l’écosystème ne rattrape les implications. Le contournement de la boîte de dialogue de confiance est la même forme à un niveau inférieur. Chaque fonctionnalité de commodité qui permet à un dépôt de pré-configurer l’agent ajoute une ligne à la taxonomie ci-dessus. Chaque ligne est une candidate pour la prochaine CVE de la classe.

L’arrière du meuble : un invariant d’ordre de chargement, pas une boîte de dialogue plus intelligente

Paul Jobs a appris à Steve que le dessous d’un meuble mérite le même soin que la finition.¹⁰ La métaphore du meuble n’est pas décorative ici. Elle est la colonne vertébrale du correctif.

Une boîte de dialogue de confiance, c’est l’arrière du meuble. Les utilisateurs ne voient pas l’ordre de chargement. Ils voient une boîte de dialogue, ils cliquent sur Approuver, et ils supposent que chaque octet à l’intérieur du workspace est inerte jusqu’à ce clic. L’implémentation doit gagner cette supposition. Quand elle ne le fait pas, la supposition devient la surface d’attaque.

L’ordre de chargement est l’invariant qui décide si la supposition est gagnée. Le modèle minimal impliqué par les deux avis et par la documentation publique des paramètres de Claude Code est approximativement :²¹⁶

1. Lire les paramètres utilisateur depuis ~/.claude/settings.json.
2. Lire les paramètres utilisateur depuis ~/.claude/settings.local.json.
3. Évaluer si le chemin du workspace courant est approuvé.
4. Si non, afficher la boîte de dialogue. Si l’utilisateur clique sur Approuver, persister le chemin.
5. Lire le .claude/settings.json à portée projet à l’intérieur du dépôt.
6. Lire le .claude/settings.local.json à portée projet.
7. Résoudre les hooks, serveurs MCP, skills et sous-agents à partir des paramètres fusionnés.
8. Exécuter les hooks SessionStart.

Les avis ne documentent pas chaque étape avec exactitude, et le placement des skills, sous-agents et MCP par rapport à la fusion des paramètres relève d’un détail d’implémentation que l’utilisateur ne voit pas. Ce que les avis établissent, en revanche, c’est la frontière à l’étape 3. Tout ce qui est résolu avant l’étape 3 se trouve dans la zone d’entrée approuvée. Tout ce qui est résolu à l’étape 3 ou après ne doit pas consulter les octets du workspace. Le bug de mars a interverti les étapes 3 et 5 : les paramètres du projet étaient résolus en premier, et le mode de permission que ces paramètres définissaient (bypassPermissions) satisfaisait trivialement la vérification de confiance à l’étape 3.² Le bug d’avril a déplacé l’attaque dans l’étape 3 elle-même : la résolution du chemin du workspace consultait un fichier commondir contrôlé par le dépôt, et une falsification faisait résoudre la vérification de confiance contre le chemin approuvé choisi par l’attaquant.¹ Dans tous les cas, lorsque l’étape 7 ou 8 arrive, le workspace est déjà approuvé, et chaque surface au niveau projet se charge sur la base de ce vote.

La règle qu’exige l’arrière du meuble tient en une phrase : n’interpréter aucun octet à l’intérieur du workspace tant que l’utilisateur n’a pas explicitement approuvé le chemin du workspace. Pas .claude/settings.json. Pas commondir. Pas CLAUDE.md. Pas une liste de noms de fichiers. Pas un fichier de hook. Pas une configuration de serveur MCP. Si cela réside à l’intérieur du workspace, le code qui décide de la confiance ne le regarde pas.

Visual Studio Code a livré ce correctif en mai 2021 sous le nom de Workspace Trust (version 1.57). La classe principale de confiance des dossiers n’a produit aucun contournement publié depuis la sortie de la fonctionnalité, bien que des problèmes adjacents autour des domaines approuvés et du comportement des extensions continuent d’apparaître.¹¹¹² La version 2.1.53, le correctif référencé par l’avis de mars, a livré la version Claude Code de l’invariant en réordonnant les étapes 3 et 5.² La version 2.1.84, le correctif référencé par l’avis d’avril, l’a livré en refusant de suivre les fichiers commondir contrôlés par le dépôt pendant l’évaluation de la confiance.¹ Les deux sont des correctifs qui rétablissent l’invariant plutôt que d’inventer une nouvelle défense.

Le test Steve tire le fil suivant : Blake signerait-il son nom sur ceci ?¹³ La réponse pour Claude Code dans cette fenêtre de six semaines est non, parce que l’éditeur a deux fois signé, livré et corrigé des contournements de cette classe. C’est la barre que l’éditeur doit relever. Minimum Worthy Product est le standard auquel renvoie cette signature.¹⁴ Le minimum est une contrainte de portée, pas une remise sur la qualité. Une boîte de dialogue de confiance minimum viable est une boîte de dialogue qui bloque le cas évident. Une boîte de dialogue de confiance minimum digne est la première étape d’un ordre de chargement qui refuse d’interpréter le moindre octet du dépôt avant que l’utilisateur n’ait décidé. Le produit que vous livrez, ce sont les octets que vous refusez d’interpréter tant que vous n’y êtes pas autorisé.

Trois correctifs qu’exige l’invariant

La règle est l’invariant. Trois patrons en découlent directement.

Barrières à sens unique. Le code qui établit la confiance ne lit que le chemin, le clic de l’utilisateur et l’état de confiance persisté en dehors du workspace dans ~/.claude.json.¹⁵ Rien d’autre. Toute refactorisation dans laquelle un fichier du workspace contribue à la décision de confiance est une régression.

Pas de confiance transitive via la résolution de chemin. L’invariant préféré est que les worktrees, les sous-modules, les fichiers d’inclusion et les cibles de liens symboliques reçoivent chacun leur propre invite. Le Workspace Trust de Visual Studio Code, en revanche, permet à la confiance d’un dossier parent de s’appliquer aux sous-dossiers, et c’est ce choix qu’exploite la confiance large sur des chemins parents comme ~/Projects lorsque la résolution de chemin est falsifiée. La règle plus stricte coûte quelques boîtes de dialogue supplémentaires et supprime toute la surface de confiance transitive ; la règle plus souple maintient une faible friction et accepte que les bugs de résolution de chemin deviennent des bugs de résolution de confiance.¹¹

Fixtures adverses dans le test de régression de l’ordre de lecture de la confiance. Un dépôt adverse délibérément conçu qui commit des fichiers de workspace canaris. Le test affirme qu’aucun chemin de code ne lit ces canaris avant que la boîte de dialogue ne soit confirmée. Si une future modification du runtime lit un quelconque fichier canari pendant l’évaluation de la confiance, la build échoue. CWE-501, Trust Boundary Violation, est la famille plus large à suivre dans la taxonomie de tests aux côtés des classifications plus spécifiques CWE-807 et CWE-20/CWE-77 que les avis publiés utilisent déjà.¹⁶

Aucun des trois n’est coûteux. Le premier est l’absence de code. Le deuxième coûte une friction visible pour l’utilisateur. Le troisième est une passe d’ingénierie suivie de discipline. La compromission de l’amorçage de la confiance est une catégorie où la posture habituelle de défense en profondeur ne s’applique pas, parce que chaque couche en aval de la confiance s’exécute contre la décision de confiance que le workspace vient juste d’aider à prendre. La défense en dehors de la confiance est impossible à construire au niveau de l’échafaudage, parce que l’échafaudage est précisément ce que le workspace peut lire une fois la confiance résolue.

L’éditeur doit livrer l’invariant. Les CVE de contournement de la boîte de dialogue de confiance sont la manière dont les observateurs mesurent si l’éditeur tient la barre. Deux en six semaines, ce n’est pas du bruit. C’est un signal que l’invariant n’a pas été codifié dans la suite de tests comme une assertion que la build impose. Tant que ce n’est pas le cas, la prochaine CVE de la classe n’est qu’une question de trouver la dixième entrée.

Le dépôt ne devrait pas pouvoir voter sur sa propre confiance. La confiance est la seule décision que l’artefact évalué ne doit pas aider à prendre. Toutes les autres couches de défense de l’agent (hooks, skills, validateurs, détecteurs, gardes) résident en aval de ce vote unique. Quand le vote est truqué, le travail en aval n’est plus que du mobilier. La finition du meuble ne sauve pas l’arrière.

FAQ

Qu’est-ce qu’un contournement de la boîte de dialogue de confiance Claude Code ?

Un contournement de la boîte de dialogue de confiance Claude Code se produit lorsqu’un workspace non approuvé est traité comme approuvé avant que l’utilisateur ne l’ait explicitement validé. Dans la CVE de mars 2026, des paramètres contrôlés par le dépôt influençaient le mode de permission avant que la confiance ne soit évaluée. Dans la CVE d’avril 2026, une disposition de worktree/commondir git forgée a fait résoudre la confiance via un chemin déjà approuvé.

Comment restreindre les chemins approuvés dans ~/.claude.json ?

Ouvrez ~/.claude.json et inspectez le mappage projects. Cherchez les entrées où hasTrustDialogAccepted est à true sur des répertoires qui n’hébergent plus de code actif, sur des chemins parents larges tels que ~/Projects, et sur tout chemin qui chevauche des dispositions adjacentes à un worktree. La confiance par dépôt ajoute des boîtes de dialogue mais empêche qu’un seul chemin parent approuvé couvre silencieusement tous ses enfants.

Pourquoi la confiance sur un chemin parent est-elle dangereuse pour Claude Code ?

La confiance sur un chemin parent est dangereuse parce qu’un seul répertoire approuvé peut couvrir de nombreux workspaces enfants. Si la résolution de chemin est falsifiée, ou si un worktree malveillant pointe vers ce parent, le dépôt enfant peut hériter d’une confiance qui ne lui a jamais été accordée. La confiance par dépôt ajoute de la friction, mais elle empêche la confiance transitive entre dépôts non liés.

Quel invariant empêche les contournements de la boîte de dialogue de confiance ?

L’invariant est : n’interpréter aucun octet à l’intérieur du workspace tant que l’utilisateur n’a pas explicitement approuvé le chemin du workspace. Le code de confiance peut lire le chemin, le clic de l’utilisateur et l’état de confiance persisté en dehors du dépôt. Il ne devrait pas lire .claude/settings.json, CLAUDE.md, .mcp.json, les hooks, les skills, commondir ou tout autre fichier contrôlé par le dépôt avant la boîte de dialogue.

Références