GhostApproval : quand l'invite d'approbation d'un agent de code masque la vraie cible

De quoi s’agit-il ?

Le 8 juillet 2026, Wiz Research a publié GhostApproval, une faille systématique de frontière de confiance présente dans six des assistants de code IA les plus populaires : Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity et Windsurf. Il s’agit d’une divulgation défensive — signalée aux six éditeurs avant publication — qui documente un angle mort commun à toute une catégorie d’outils plutôt qu’une attaque inédite contre un produit isolé.

Le problème central n’a rien d’exotique. Il combine une primitive vieille de plusieurs décennies — le suivi de lien symbolique (CWE-61) — avec un élément plus récent et plus intéressant : l’invite de confirmation affichée par ces agents ne révèle pas où l’écriture va réellement aboutir. L’humain est en théorie « dans la boucle », mais la boucle est alimentée par une information trompeuse.

Comment ça marche

Un dépôt malveillant embarque un fichier d’apparence banale, par exemple project_settings.json, qui est en réalité un lien symbolique pointant hors de l’espace de travail — vers ~/.ssh/authorized_keys, ~/.zshrc ou une autre cible sensible. Le README du dépôt contient des instructions en clair du type « pour installer ce projet, mettez à jour project_settings.json avec ce qui suit », accompagnées d’une clé publique SSH fournie par l’attaquant.

Lorsque le développeur clone le dépôt et demande à son assistant de « configurer l’espace de travail » ou de « suivre le README », l’agent lit l’instruction et écrit dans project_settings.json. Comme l’outil ne résout jamais le lien symbolique vers son chemin canonique, l’écriture atterrit sur la vraie cible. La clé de l’attaquant est ajoutée à authorized_keys, ce qui ouvre un accès distant persistant et sans mot de passe — le schéma du député confus appliqué à un rédacteur de fichiers autonome.

Le second échec, plus tranchant, est une erreur de représentation de l’interface (CWE-451). Wiz a observé plusieurs agents dont le raisonnement interne reconnaissait explicitement le danger — l’un indiquait que le fichier « est en fait un fichier de configuration zsh » — tandis que la boîte de dialogue présentée à l’utilisateur demandait seulement « Appliquer cette modification à project_settings.json ? ». L’agent savait ; l’utilisateur n’était pas prévenu. Cela transforme un contrôle de bac à sable en contournement du consentement éclairé : le consentement est formellement présent mais substantiellement vide.

Wiz a trouvé des variantes sur les six outils. Certains (Amazon Q Developer, Windsurf) écrivaient sur le disque avant l’apparition des boutons d’approbation, faisant de la boîte de dialogue une annulation plutôt qu’un point de contrôle. Augment effectuait à la fois des lectures via lien symbolique — affichant dans le chat le contenu d’un fichier situé hors de l’espace de travail — et des écritures sans aucune confirmation. La preuve de concept tient en un dépôt configuré en deux lignes : la barrière à l’exploitation est une pull request ou une dépendance, pas une compétence pointue.

Pourquoi c’est important

Le « human-in-the-loop » est le principal argument de sûreté des agents de code autonomes, et GhostApproval montre à quel point cet argument peut être ténu quand la boucle manque d’information fiable. Le sujet rejoint des travaux antérieurs sur l’approbation et les liens symboliques comme SymJack, mais l’accent porte ici sur la frontière de confiance et le consentement : le contrôle de sécurité existe, mais il n’expose pas ce dont l’utilisateur a besoin pour décider.

Les réponses des éditeurs se sont divisées, ce qui est instructif en soi. Google, AWS et Cursor ont traité la faille comme une vulnérabilité et publié des correctifs. Anthropic a contesté que le comportement de Claude Code soit un bug, arguant qu’un utilisateur qui fait confiance à un répertoire et approuve une édition assume cette décision — plaçant le scénario du répertoire trompeur hors de son modèle de menace (Anthropic a par ailleurs indiqué qu’un avertissement sur les liens symboliques était déjà présent dans une version de durcissement antérieure). Le désaccord est une vraie question de philosophie de conception : un outil doit-il protéger l’utilisateur d’un espace de travail conçu pour le tromper, ou repérer un dépôt malveillant relève-t-il de la responsabilité de l’utilisateur ? Pour les développeurs qui font tourner des agents sur du code tiers non fiable — précisément l’usage vendu par ces outils — la réponse pratique doit rester défensive, quelle que soit la ligne retenue. C’est la même leçon que le problème des agents trop zélés : une capacité sans surface de contrôle fidèle est un danger.

Défenses

Résolvez les liens symboliques avant d’afficher l’invite. Le correctif recommandé par Wiz consiste à canoniser le chemin cible et à afficher la destination résolue dans la boîte de dialogue. Une écriture dans ~/.ssh/authorized_keys ne doit jamais s’afficher comme une modification de ./config.json.

Faites de la boîte de dialogue un point de contrôle, pas une annulation. N’écrivez jamais sur le disque avant l’autorisation explicite. Les écritures avant autorisation annulent tout l’intérêt de la supervision humaine — au moment où vous cliquez, le mal est fait.

Alertez sur toute écriture hors de l’espace de travail. Traitez les écritures dont le chemin canonique sort de la racine du projet comme à haut risque et exigez une confirmation explicite et renforcée qui nomme le vrai fichier.

Isolez les dépôts non fiables et désactivez l’approbation automatique. Faites tourner les agents sur du code inconnu dans un environnement isolé, et coupez les modes d’auto-approbation pour les projets tiers. Mettez à jour les outils corrigés (Amazon Q Developer, Cursor, Google Antigravity) ; pour les autres, considérez que le comportement est toujours présent.

Surveillez les cibles sensibles. Déclenchez une alerte sur les modifications de ~/.ssh/authorized_keys, des fichiers rc du shell et des autres chemins de persistance — surtout lorsque le processus qui écrit est un assistant de code IA opérant sur un dépôt fraîchement cloné.

Statut

Éditeur / outil	Statut	Référence
Amazon Q Developer	Corrigé (language server 1.69.0)	CVE-2026-12958 (advisory AWS)
Cursor	Corrigé (v3.0)	CVE-2026-50549 (advisory Cursor)
Google Antigravity	Corrigé ; évaluation CVE en cours	—
Augment	Accusé de réception, pas de correctif à la divulgation	—
Windsurf	Accusé de réception, pas de correctif à la divulgation	—
Anthropic Claude Code	Contesté (« hors modèle de menace ») ; avertissement lien symbolique noté dans une version antérieure	—
Divulgation	Découverte le 10 fév. 2026 ; publication le 8 juil. 2026 (Wiz Research)	—