GhostApproval : Six assistants de codage IA ont demandé l’autorisation et nommé le mauvais fichier

Le 8 juillet 2026, la société de sécurité Wiz a publié GhostApproval, une découverte de recherche dans laquelle un lien symbolique implanté dans un dépôt a amené six assistants de codage IA à écrire en dehors de leur espace de travail — dans ~/.ssh/authorized_keys, qui accorde un accès SSH persistant sans mot de passe, ou dans ~/.zshrc, qui s'exécute au prochain démarrage du shell — alors que la boîte de dialogue de confirmation ne nommait que le fichier inoffensif que le lien prétendait être. Wiz a testé Amazon Q Developer, Claude Code d'Anthropic, Augment, Cursor, Google Antigravity et Windsurf, et a signalé ce schéma dans les six. Aucune exploitation dans la nature n'a été signalée : ce travail est une démonstration de preuve de concept, et l'entrée d'archive ne consigne aucun préjudice réel. Trois éditeurs ont publié des correctifs, deux ont accusé réception du rapport puis ont cessé de répondre, et un a contesté qu'il s'agisse même d'une vulnérabilité. L'Orca AI Incident Archive contient le dossier complet de cette découverte aux côtés des autres entrées classées sous son étiquette de type SANDBOX.

La primitive elle-même est une vieille histoire. Le suivi de liens symboliques, répertorié sous CWE-61, constitue une primitive d’attaque depuis des décennies — Wiz cite des usages antérieurs dans des conditions de concurrence, des gestionnaires de paquets et des évasions de conteneur — et chacun de ces cas dépendait d’un outil écrivant vers un chemin contrôlé par l’utilisateur sans le résoudre au préalable. Ce qui a rendu cette découverte digne d’un nom, c’est la seconde couche : dans plusieurs produits, le raisonnement de l’assistant lui-même a identifié la destination dangereuse, et l’invite présentée à l’humain la masquait. Wiz classe cela sous CWE-451, présentation trompeuse d’informations critiques dans l’interface utilisateur. La frontière de sécurité était présente. L’information dont une personne avait besoin pour l’exercer ne l’était pas.

Comment le tour fonctionne, et sur quoi il atterrit

Le dépôt malveillant de Wiz est volontairement ennuyeux. Il contient un lien symbolique nommé project_settings.json qui pointe vers le fichier de clés autorisées SSH du développeur, ainsi qu'un README demandant à l'agent de mettre à jour cette « config » lors de la configuration de l'espace de travail. Lorsque le développeur demande à l'assistant de suivre le README, l'agent suit le lien et écrit la clé publique de l'attaquant. Si la machine exécute un service SSH que l'attaquant peut atteindre, cela permet dès lors une connexion sans mot de passe. Une deuxième variante pointe le même leurre vers ~/.zshrc, de sorte que la charge utile s'exécute la prochaine fois qu'un terminal s'ouvre et qu'aucun accès SSH n'est nécessaire.

La description par Wiz de la défaillance technique est brève : le bac à sable, lorsqu’il existe, ne valide pas le chemin canonique, de sorte qu’une écriture visant l’intérieur du projet aboutit là où pointe le lien. La preuve de concept de l’entreprise a reproduit ce phénomène sur « 6 des meilleurs assistants de codage IA », selon ses propres termes, et elle a publié des captures d’écran pour chacun. La population concernée est toute personne qui ouvre, dans l’un de ces outils, un dépôt dont elle n’est pas l’auteur — ce qui, dans le flux de travail normal d’un développeur, inclut les projets forkés, les dépendances tierces et toute revue de code de la branche d’un contributeur externe.

La boîte de dialogue qui a nommé le mauvais fichier

La preuve la plus claire est venue de Claude Code. Dans le test de Wiz, le raisonnement de l'agent indiquait, selon la citation de l'entreprise : « Je peux voir que project_settings.json est en réalité un fichier de configuration zsh. » L'invite d'autorisation présentée à l'utilisateur demandait : « Appliquer cette modification à project_settings.json ? » L'agent savait où l'écriture allait être effectuée ; la personne qui l'autorisait, non. Wiz qualifie le consentement qui en résulte de « vide sur le fond » et le contrôle humain dans la boucle de simple « coup de tampon ».

Trois produits ont aggravé l’écart au-delà d’une simple étiquette erronée. Windsurf a écrit le fichier sur le disque avant que les boutons Accepter et Rejeter n’apparaissent, si bien que la boîte de dialogue permettait d’annuler plutôt que de constituer un point de contrôle d’autorisation — au moment où un utilisateur pouvait refuser, la clé était déjà en place, selon Wiz. Amazon Q Developer présentait le même ordre des opérations, n’offrant qu’un bouton Annuler après l’écriture. Augment ne demandait rien du tout : Wiz a démontré une lecture via lien symbolique qui a fait apparaître, dans la transcription de la conversation, un fichier leurre d’identifiants AWS provenant de l’extérieur du projet, et une écriture via lien symbolique vers ~/.ssh/authorized_keys sans aucune boîte de dialogue, quelle qu’elle soit. À l’inverse, Cursor et Google Antigravity affichaient le chemin non résolu et demandaient un clic qui autorisait le chemin résolu.

Le premier test de Wiz a été réalisé le 10 février 2026 et les rapports ont été envoyés entre le 12 février et le 5 mars. Sa chronologie de divulgation consigne les accusés de réception : Anthropic le 15 février, Augment le 24 février, Google le 26 février, Cursor le 2 mars, AWS le 6 mars et Cognition, propriétaire de Windsurf, le 23 juin. La divulgation publique a suivi environ cinq mois après le premier rapport.

Six fournisseurs, trois réponses

Wiz évalue les conclusions selon sa propre échelle de gravité, de High chez AWS à Critical chez Augment, Cursor, Google Antigravity et Windsurf. Trois fournisseurs ont traité le rapport comme une vulnérabilité et publié un correctif. L'archive attribue à l'entrée une gravité élevée et une note A en confiance, et les avis principaux concordent avec Wiz sur le mécanisme.

• Amazon Web Services. Gravité élevée, suivi sous CVE-2026-12958 et corrigé dans Language Servers for AWS 1.69.0. Le bulletin 2026-047-AWS d'AWS lui-même, publié le 23 juin 2026, confirme « un problème de validation de lien symbolique manquant » avant la version 1.69.0 et liste les versions minimales des plugins contenant le correctif : Amazon Q Developer pour Visual Studio Code 2.20, pour JetBrains 4.3, pour Eclipse 2.7.4, et AWS Toolkit avec Amazon Q pour Visual Studio 1.94.0.0. Il indique qu'il n'existe aucun contournement, que le serveur linguistique se met à jour automatiquement sauf si une configuration réseau l'en empêche, et remercie Wiz pour la divulgation coordonnée. La fiche CNA attribue à la vulnérabilité une note de 8,5 selon CVSS 4.0 et de 7,8 selon CVSS 3.1.

• Cursor. Critique, suivie sous CVE-2026-50549 et corrigée dans Cursor 3.0. L'enregistrement a été publié par GitHub en tant que CNA le 25 juin 2026, avec un score de 9,3 selon CVSS 4.0. Sa description présente l'attaquant de manière légèrement différente du récit du dépôt de Wiz : un agent malveillant crée un lien symbolique dans l'espace de travail et force l'échec de la canonicalisation du chemin, soit parce que la cible n'existe pas, soit parce que l'autorisation de lecture a été retirée du chemin, après quoi l'écriture revient au chemin d'origine sans approbation et peut écraser l'utilitaire d'assistance du bac à sable pour permettre une exécution hors bac à sable.

• Google. Wiz classe Antigravity comme critique et consigne le correctif sous la version 1.19.6, déployée le 22 mai 2026. Sa colonne de gravité indique « En attente » et, selon le compte rendu de Wiz, Google évaluait l'opportunité d'émettre un CVE ; aucun identifiant CVE pour Antigravity n'apparaît dans les sources publiques.

• Augment. Critique selon l'évaluation de Wiz, testée sur la version 0.754.3, reconnue le 24 février 2026 et non corrigée au moment de la publication. La note de recherche de la Cloud Security Alliance sur cette découverte rapporte la contre-argumentation d'Augment selon laquelle un agent opère avec les propres identifiants de l'utilisateur.

• Windsurf. Critique selon l’évaluation de Wiz, testé sur la build V1.9566, confirmé par Cognition le 23 juin 2026 et non corrigé au moment de la publication.

• Anthropic. Contesté. Aucune CVE, et la version testée de Claude Code, 2.1.42, figure dans le tableau de Wiz avec le statut « Rejeté ».

Le rejet d’Anthropic, et le correctif qui précède le rapport

La réponse d’Anthropic à Wiz a été un non mûrement réfléchi. « Cela sort du cadre de notre modèle de menace actuel », a écrit l’entreprise, selon la citation de Wiz. « Lorsqu’un utilisateur démarre Claude Code pour la première fois dans un répertoire, il doit confirmer qu’il fait confiance à ce répertoire avant de démarrer la session. Le scénario que vous décrivez implique qu’un utilisateur confirme explicitement une demande d’autorisation dans un répertoire contenant un lien symbolique malveillant, ce qui sort du modèle de menace de Claude Code. » Le ticket a été clôturé avec la mention « informatif ».

Ce raisonnement a une forme cohérente : l'utilisateur a fait confiance au répertoire, puis a approuvé l'opération, si bien que les deux moments de consentement ont été respectés. La réfutation de Wiz est que le consentement éclairé exige une information exacte — approuver project_settings.json alors que l'écriture atterrit dans ~/.ssh/authorized_keys est formellement une décision et, sur le fond, une décision vide. Wiz ne prétend pas avoir tranché laquelle de ces positions est la bonne, et cet article non plus. L'observation pratique est qu'AWS, Google et Cursor ont retenu l'autre point de vue et ont corrigé.

Wiz a également rapporté que Claude Code avait changé en cours de litige : les versions actuelles, a écrit l’entreprise, résolvent les liens symboliques et avertissent avant d’écrire dans des fichiers sensibles, et elle a noté qu’Anthropic avait refusé de dire si cela était lié au rapport. Le 7 juillet 2026, Anthropic a fourni une correction, citée par Wiz : « L’avertissement sur les liens symboliques dans la boîte de dialogue d’autorisation Modifier/Écrire a été déployé dans la v2.1.32 (5 février 2026), neuf jours avant que ce rapport ne nous soit soumis. Il a été ajouté dans le cadre d’un renforcement proactif de la sécurité fondé sur un examen interne. Le refus de commenter était une réponse automatique de notre système de triage. »

La concordance temporelle de la version est correcte ; le registre public de ce qui a changé ne l’est pas. Claude Code 2.1.32 a été publié dans le registre npm le 5 février 2026 à 17:03 UTC, soit neuf jours avant le rapport du 14 février, exactement comme l’affirme Anthropic. Mais l’entrée du journal des modifications public pour cette version énumère douze changements, notamment les équipes d’agents, l’enregistrement de la mémoire et plusieurs correctifs d’interface, et aucun ne mentionne les liens symboliques ni les boîtes de dialogue d’autorisation. Les premières lignes du journal des modifications qui décrivent exactement ce comportement sont bien plus tardives : la version 2.1.280, publiée sur npm le 22 septembre 2026, consigne « Correction des écritures via un chemin lié symboliquement qui étaient jugées selon leur orthographe dans l’arborescence : l’invite indique où l’écriture aboutit », et la 2.1.287 du 1er octobre 2026 consigne qu’une écriture shell via un lien symbolique commité dans le dépôt vers un fichier sensible indique désormais où elle aboutit et attend l’intervention d’une personne. L’observation de Wiz lui-même selon laquelle 2.1.173 et les versions ultérieures résolvent les liens symboliques arrive elle aussi après le rapport, puisque 2.1.173 a été livrée le 11 juin 2026.

Ce qui est établi, et ce qui ne l’est pas

• Confirmé. Le mécanisme : un lien symbolique leurre dans un dépôt, un agent qui le suit, une écriture qui aboutit en dehors de l’espace de travail, et une surface de confirmation qui désigne le mauvais chemin. Wiz l’a reproduit dans les six produits et a publié des captures d’écran. Deux fiches CVE existent et sont publiées par leurs CNA, et le bulletin d’AWS confirme indépendamment la faille des versions antérieures à 1.69.0 et le correctif. Anthropic ne conteste pas que le comportement se soit produit ; elle conteste qu’il s’agisse d’une vulnérabilité.

• Source unique. Les évaluations de gravité pour Augment, Windsurf et Google Antigravity sont des jugements de Wiz, et non des scores CNA, car aucun CVE n’a été publié pour aucun des trois. L’affirmation selon laquelle Windsurf et Amazon Q écrivent avant l’apparition de la boîte de dialogue repose sur les captures d’écran et le récit de Wiz ; aucun fournisseur n’a confirmé cet ordre publiquement.

• Contesté. La question de savoir si un outil doit à son utilisateur une protection contre un espace de travail trompeur, ou si la confiance accordée au répertoire conjuguée à un clic suffit à trancher. Anthropic défend la seconde thèse ; Wiz affirme que l'invite qu'il a affichée rendait le clic dénué de sens. L'archive ne signale pas la fiche comme contestée : les faits font consensus et seule l'interprétation est contestée.

• Non établi.La question de savoir si Augment et Windsurf ont corrigé la faille depuis la publication. Toutes les sources examinées pour cet article, y compris la note de la Cloud Security Alliance du 15 juillet 2026, décrivent toujours les deux comme non corrigés ; aucun avis public de correction de la part de l’un ou l’autre fournisseur n’a été trouvé.

La date elle-même comporte une petite subtilité. L’article de Wiz et sa chronologie de divulgation indiquent tous deux le 8 juillet 2026, Infosecurity Magazine décrit la preuve de concept comme publiée le 7 juillet et son propre rapport comme daté du 9 juillet, et l’entrée d’archive est datée du 9 juillet 2026 à la précision du jour. La découverte, la couverture médiatique et l’archive ne sont pas en désaccord sur la semaine ; le désaccord porte sur le jour, avec un écart pouvant aller jusqu’à deux jours.

Les travaux antérieurs sur l’une des six méritent un crédit distinct. Evan Schuman, de CSO Online, dans un article du 9 juillet 2026, a souligné que Cato Networks avait signalé une version de la faille propre à Cursor avant l’étude plus large de Wiz. Le compte rendu de SecurityWeek sur ces recherches, publié le 3 juillet 2026, la nomme DuneSlide, attribue CVE-2026-50548 et CVE-2026-50549 au duo, leur attribue à toutes deux une note de 9,8 et situe au 2 avril la version Cursor 3.0 qui les a corrigées — des chiffres qui ne concordent ni avec la chronologie de Wiz, qui situe la publication du correctif de Cursor au 5 juin, ni avec la fiche CNA publiée le 25 juin avec une note de 9,3. Le 9,8 et le 9,3 sont deux notes attribuées à la même faille ; les dates d’avril et de juin peuvent décrire une version et un avis plutôt qu’exprimer un désaccord sur la date de diffusion du correctif.

Qu’est-ce qui a changé par la suite ?

Concrètement : les utilisateurs d'Amazon Q Developer ont été migrés vers le serveur de langage 1.69.0, automatiquement dans la plupart des configurations ; les utilisateurs de Google Antigravity vers 1.19.6 à partir du 22 mai 2026 ; les utilisateurs de Cursor vers 3.0 ; et les utilisateurs de Claude Code vers une version qui résout les liens, avec d'autres changements de fidélité des invites arrivant dans 2.1.280 et 2.1.287 en septembre et octobre 2026. Les utilisateurs d'Augment et de Windsurf, selon les éléments disponibles au moment de la publication, n'ont obtenu qu'une date à surveiller, et rien d'autre.

Les recommandations propres à Wiz étaient étroites et techniques : résoudre les liens symboliques avant d’afficher une invite, avertir explicitement lorsque le chemin résolu sort de l’espace de travail, et ne jamais écrire sur le disque avant une autorisation explicite, afin que la boîte de dialogue soit une barrière plutôt qu’un bouton d’annulation. La note de la Cloud Security Alliance ajoute un cadre de gouvernance — considérer les assistants de codage comme des logiciels privilégiés ayant accès au système de fichiers plutôt que comme des plugins d’éditeur, et demander directement aux fournisseurs si les chemins sont résolus avant l’apparition d’une confirmation. Katie Norton, d’IDC, citée par CSO Online, situe le risque résiduel là où la chaîne d’approvisionnement est déjà à l’œuvre : les contributeurs externes, les dépôts dérivés (forks) et les dépendances tierces, « plutôt que dans le code écrit en interne ».

Ce qui reste ouvert, c’est la question de conception, pas le bug. Six produits développés indépendamment ont convergé vers la même séquence — afficher le chemin demandé, faire confiance au clic — et la divergence qui a suivi portait sur la responsabilité, pas sur le mécanisme. L’entrée d’archive comporte un indicateur de référence, qui correspond au jugement de l’archive selon lequel l’enregistrement décrit une catégorie plutôt qu’une erreur d’un seul fournisseur, et il est difficile de contester cette lecture : la même courte preuve de concept a fonctionné six fois.