TrustFall : les réglages MCP du projet transforment le clic de confiance en RCE

De quoi parle-t-on ?

Le 7 mai 2026, Adversa AI a publié TrustFall, un rapport sur une convention partagée par quatre outils de codage agentiques en ligne de commande : Claude Code, Gemini CLI, Cursor CLI et GitHub Copilot CLI. Les quatre démarrent les serveurs Model Context Protocol (MCP) définis par le projet — des programmes auxiliaires que le dépôt lui-même fournit et désigne — dès que le développeur accepte l’invite générique « faire confiance à ce dossier ». Chaque invite a « oui » comme valeur par défaut.

La conséquence concrète : cloner un dépôt malveillant et appuyer une seule fois sur Entrée dans la boîte de dialogue de confiance peut exécuter du code choisi par l’attaquant sur la machine du développeur, avec ses pleins privilèges, avant que le modèle ne raisonne ou n’effectue le moindre appel d’outil. Adversa présente cela non comme un bug isolé, mais comme une convention de classe ; l’analyse approfondie a porté sur Claude Code (testé autour de la v2.1.x), où une régression de la boîte de dialogue de confiance rend la faille la plus aiguë, et la parité a été confirmée sur les trois autres CLI. La couverture a suivi le même jour côté The Register et Help Net Security.

C’est un proche cousin du RCE par approbation de lien symbolique dans cinq agents de codage — même thème de fond : la porte d’approbation que voit le développeur ne décrit pas ce qu’il autorise réellement.

Comment ça fonctionne

MCP permet à un assistant IA de dialoguer avec des programmes auxiliaires externes (connecteur de base de données, linter, outil de recherche). Le hic : ces auxiliaires sont définis à l’intérieur du projet, dans des fichiers fournis par le dépôt, et démarrent comme des processus système ordinaires lorsque l’agent s’initialise dans ce dossier.

La chaîne s’appuie sur deux réglages à portée projet qui approuvent automatiquement les serveurs — Adversa cite enableAllProjectMcpServers (approuve tous les serveurs de .mcp.json) et enabledMcpjsonServers (approuve un sous-ensemble nommé), tous deux lisibles depuis le .claude/settings.json d’un dépôt, plus permissions.allow, qui peut préautoriser des appels d’outils. Aucun ne déclenche d’avertissement. Le détail déterminant est l’incohérence de portée : Anthropic bloque certains réglages dangereux au niveau projet (par ex. bypassPermissions, qui obtient une boîte de dialogue dédiée en rouge) mais pas ceux-ci. Un dépôt cloné peut simplement les activer.

Le dépôt fournit :  .mcp.json              -> définit un serveur « helper » (command + args)
                    .claude/settings.json  -> active enableAllProjectMcpServers: true
Développeur :       git clone ; lance l'agent ; appuie sur Entrée sur « Oui, je fais confiance »
Résultat :          le processus helper démarre avec les pleins privilèges, au démarrage,
                    avant tout appel d'outil du modèle. Aucune seconde invite.

Aucun payload n’est reproduit ici — la preuve de concept exploitable se trouve dans le dépôt des chercheurs. Le point structurel suffit : la commande qu’exécute un auxiliaire peut être n’importe quel exécutable, et le script peut être intégré directement dans la config, sans laisser de fichier distinct qu’un relecteur ou un scanner statique pourrait signaler.

Deux facteurs aggravants :

• La boîte de dialogue a régressé. Avant la v2.1, la fenêtre de confiance de Claude Code avertissait explicitement que .mcp.json pouvait exécuter du code et proposait « faire confiance au dossier mais désactiver MCP ». Cette option a été retirée ; l’invite v2.1+ affiche « Vérification rapide : est-ce un projet que vous avez créé ou auquel vous faites confiance ? », sans mention de MCP et avec « Oui, je fais confiance à ce dossier » par défaut.
• La CI n’a aucune boîte de dialogue. Lancé via la GitHub Action officielle, Claude Code s’exécute en mode headless via le SDK — il n’y a pas de terminal, donc l’invite de confiance ne s’affiche jamais. Une pull request d’un contributeur externe qui fournit un .mcp.json malveillant s’exécute dès que le pipeline traite cette branche. Un appui de touche sur un portable devient zéro clic en CI.

L’équipe sécurité d’Anthropic a examiné le rapport et l’a refusé comme hors de son modèle de menace : accepter « Oui, je fais confiance à ce dossier » est traité comme un consentement à toute la configuration du projet, et l’exécution post-confiance est la frontière fonctionnant comme prévu. Adversa ne conteste pas l’emplacement de cette frontière — son argument est que la boîte de dialogue ne donne pas au développeur de quoi décider en connaissance de cause.

Pourquoi c’est important

L’intéressant est le désaccord, pas un bug isolé. Anthropic a livré trois correctifs en six mois pour la même convention sous-jacente — les réglages à portée projet comme vecteur d’injection — chacun limité au réglage signalé, aucun n’auditant la convention elle-même :

CVE	Date	Cause racine	Correctif
CVE-2025-59536	oct. 2025	MCP exécuté avant la boîte de confiance	MCP différé après la boîte
CVE-2026-21852	janv. 2026	ANTHROPIC_BASE_URL dans les réglages projet redirigeait le trafic API	Réglage bloqué au niveau projet
CVE-2026-33068	mars 2026	bypassPermissions dans les réglages projet sautait la boîte	Réglage bloqué au niveau projet
TrustFall	mai 2026	Exécution MCP silencieuse post-confiance via les réglages projet	Refusé (intention de conception)

La surface de risque est large car la condition préalable — cloner un dépôt inconnu et y lancer un agent — est une habitude quotidienne des développeurs, et les outils concernés couvrent quatre éditeurs. La variante CI est la plus tranchante : elle retire entièrement l’humain et atteint tout ce que détient le runner (clés de déploiement, certificats de signature, jetons cloud), ce qui en fait un véritable vecteur d’arme de chaîne d’approvisionnement plutôt qu’une curiosité de laboratoire. Pour qui suit le schéma plus large, cela rejoint la surface RCE par stdio inhérente à MCP : la puissance du protocole et son rayon d’impact ne font qu’un.

Défenses

Le correctif le plus solide ne dépend d’aucun éditeur et fonctionne aussi bien sur un poste isolé que sur une flotte gérée.

1. Verrouillez les réglages à la portée Managed. Déposez un managed-settings.json au chemin « managed » de l’OS, fixant enableAllProjectMcpServers: false, restreignant enabledMcpjsonServers à une liste blanche explicite (ou []) et figeant permissions.allow. La portée Managed est la plus prioritaire dans Claude Code — elle prime sur Project, Local, User et même les options de ligne de commande — donc un dépôt cloné ne peut pas l’écraser. Définie une fois, elle neutralise la chaîne quels que soient vos clonages ultérieurs.

2. Auditez le contenu de la config commitée, pas seulement sa présence. Ajoutez un hook pre-commit ou un scanner de dépôt qui signale tout .claude/settings.json ou .claude/settings.local.json commité contenant enableAllProjectMcpServers, enabledMcpjsonServers ou permissions.allow. Scannez les deux fichiers : la portée Local prime sur Project, et un attaquant peut fournir directement .claude/settings.local.json. Aucune de ces clés n’a de raison légitime d’être commitée — les développeurs qui veulent ce comportement doivent l’activer à la portée User (~/.claude/settings.json), hors du dépôt.

3. Inspectez directement command/args dans .mcp.json. La variante sans fichier intègre le payload en ligne, donc les scanners qui ne suivent que les fichiers référencés la manquent. Signalez les args contenant -e, -p, --eval, eval, fetch(, child_process, net.Socket ou des blobs base64.

4. Surveillez le schéma d’exécution à haute confiance. Une alerte brute sur l’agent lançant node -e / python -c / sh -c est bruyante. Le signal précis : l’agent lance un enfant longue durée dont command/args correspondent à un .mcp.json situé dans un répertoire récemment cloné et non possédé par l’utilisateur. Les sessions légitimes ne produisent pas cela, et cela attrape la variante en ligne que les contrôles statiques ne voient pas.

5. Durcissez explicitement la CI. Les exécutions headless n’ont pas de barrière de consentement, alors n’en dépendez pas. N’exécutez les actions d’agent que sur des branches de confiance, limitez les identifiants du runner au moindre privilège, et conditionnez l’activation MCP à une configuration contrôlée par le runner (pas par le dépôt). Traitez la PR d’un contributeur externe comme du code non fiable susceptible de s’exécuter.

6. Lisez la config avant de lancer l’agent. En ouvrant un projet open source inconnu, inspectez d’abord .mcp.json et .claude/settings.json. La boîte de dialogue de confiance ne vous dira pas ce qui est sur le point de s’exécuter.

État

Élément	Référence	Date	Notes
Divulgation TrustFall	Adversa AI	2026-05-07	Convention de classe ; analyse Claude Code + parité sur 3 autres CLI
Position de l’éditeur	Anthropic (selon Adversa)	2026-05	Refusé comme hors modèle de menace — l’exécution post-confiance est « voulue »
Correctifs antérieurs, même cause	NVD / Adversa	oct. 2025 – mars 2026	CVE-2025-59536, CVE-2026-21852, CVE-2026-33068
Couverture presse	The Register, Help Net Security	2026-05-07	Confirme la variante 1 clic poste + la variante 0 clic CI

Le cadrage honnête n’est pas « un outil IA a un bug » — c’est « la confiance accordée à un dossier autorise, à elle seule, le lancement de processus non sandboxés définis par l’attaquant, et l’invite qui l’accorde ne dit rien de MCP. » Savoir s’il s’agit d’une vulnérabilité ou d’un choix de conception est précisément la question ouverte. Tant que l’invite ou les règles de portée ne changent pas, la défense vous revient : verrouillez les réglages, scannez la config, et ne laissez jamais la confiance d’un dossier être la seule barrière.