Ce qu'il faut retenir
- Wiz a testé une technique baptisée GhostApproval sur six assistants IA de code (Claude Code, Amazon Q Developer, Cursor, Google Antigravity, Augment, Windsurf) : un lien symbolique caché dans un dépôt peut rediriger une édition anodine vers un fichier système sensible.
- La faille exploite un mécanisme Unix vieux de plusieurs décennies (le suivi des liens symboliques) combiné à une interface qui n'affiche pas le chemin réel dans la boîte de dialogue de confirmation, rendant l'approbation humaine inefficace.
- AWS, Google et Cursor ont confirmé et corrigé la faille. Anthropic a ajouté des mitigations avant même le rapport de Wiz sans considérer cela comme une vulnérabilité. Augment et Windsurf ont accusé réception sans avoir publié de correctif au moment du rapport.
Résumé généré par IA
Des chercheurs de Wiz ont démontré qu'il suffit d'un lien symbolique caché dans un dépôt de code pour transformer six assistants IA de développement parmi les plus utilisés au monde en un vecteur de compromission de votre poste de travail. La technique, baptisée GhostApproval, a été testée avec succès contre Claude Code, Amazon Q Developer, Cursor, Google Antigravity, Augment et Windsurf.
Si vous laissez déjà un agent IA lire, modifier ou committer du code sur votre machine, cet article vous concerne directement.
Un mécanisme Unix vieux de plusieurs décennies
Le principe exploité par Wiz n'a rien de neuf : le suivi des liens symboliques (symlinks) existe depuis les débuts d'Unix. Un symlink est un fichier qui pointe vers un autre emplacement du système de fichiers. Quand un programme l'ouvre, il résout et manipule la cible réelle du lien, pas le raccourci lui-même. C'est exactement ce comportement, connu et documenté depuis des décennies, que les chercheurs ont réussi à retourner contre les agents de codage IA les plus modernes du marché.
Comment fonctionne l'attaque GhostApproval
Le scénario est simple à monter et redoutable en pratique. Un attaquant dépose, dans un dépôt en apparence anodin, un lien symbolique déguisé en fichier de projet ordinaire : un fichier de configuration, un composant, un script quelconque. En réalité, ce lien pointe vers un emplacement sensible situé hors de l'espace de travail, par exemple un fichier système, un fichier de configuration shell ou une clé.
Quand un développeur clone ce dépôt et demande à son assistant IA d'y apporter une modification, l'agent suit le lien symbolique et écrit à l'emplacement visé par l'attaquant, pas dans le fichier apparent du projet. Selon Wiz, cette chaîne peut aller jusqu'à l'exécution de code à distance sur la machine du développeur.
Pourquoi la confirmation humaine ne suffit plus
Beaucoup de ces outils intègrent justement un garde-fou pour ce genre de situation : un sandbox ou une boîte de dialogue de confirmation censée intercepter l'écriture et demander l'accord de l'utilisateur avant de l'exécuter. Sur le papier, c'est le principe du Human-in-the-Loop.
Le problème, selon Wiz, ne se limite pas au suivi du symlink. Plusieurs de ces outils échouent à résoudre et afficher le chemin canonique réel dans la fenêtre de confirmation. Le développeur voit défiler ce qui ressemble à une modification locale inoffensive, l'approuve, et l'agent modifie en silence un fichier système. Les chercheurs de Wiz résument le problème ainsi : le modèle de sécurité Human-in-the-Loop ne fonctionne que si la boucle fournit une information exacte, et quand un agent affiche une chose tout en en faisant une autre, l'approbation de l'utilisateur ne veut plus rien dire. Pour Wiz, la boîte de dialogue de confirmation cesse alors d'être un contrôle de sécurité pour devenir une simple formalité.
Six outils testés, des réponses très différentes selon l'éditeur
Wiz a signalé ses découvertes à chaque éditeur concerné dès le premier trimestre 2026. Voici où en sont les correctifs à la publication de son rapport :
- AWS, pour Amazon Q Developer : vulnérabilité confirmée, correctif déployé.
- Google, pour Antigravity : vulnérabilité confirmée, correctif déployé.
- Cursor : vulnérabilité confirmée, correctif déployé.
- Anthropic, pour Claude Code : ne considère pas ce comportement comme une vulnérabilité à proprement parler, mais indique avoir ajouté des mitigations contre ce type d'attaque avant même la publication du rapport de Wiz.
- Augment : réception du signalement confirmée, sans correctif publié à ce stade selon Wiz.
- Windsurf : réception du signalement confirmée, sans correctif publié à ce stade selon Wiz.
Comment vous protéger concrètement
En attendant que l'ensemble des éditeurs publient un correctif, plusieurs réflexes limitent concrètement le risque, que vous soyez développeur solo ou responsable technique d'une PME.
Inspectez les dépôts avant de les ouvrir dans un agent IA en mode autonome. La commande :
find . -type l -lsliste tous les liens symboliques d'un répertoire cloné et affiche leur cible réelle.
- Vérifiez le chemin affiché dans les fenêtres de confirmation de votre outil. Si le chemin proposé ne correspond pas exactement au fichier que vous pensez éditer, arrêtez-vous et vérifiez à la main avec
realpathsur le fichier concerné. - Ne laissez pas un agent IA opérer avec les mêmes droits que votre utilisateur principal sur des dépôts dont vous ne maîtrisez pas l'origine. Un conteneur de développement jetable isole l'agent du reste du système de fichiers, ce qui limite fortement l'impact d'un symlink piégé.
- Mettez à jour vos outils. Amazon Q Developer, Google Antigravity et Cursor disposent déjà d'un correctif contre GhostApproval selon Wiz : être à jour élimine ce vecteur précis pour ces trois outils.
- Si vous utilisez Augment ou Windsurf, restez prudent en attendant un correctif officiel et évitez d'ouvrir des dépôts non audités dans ces outils avec des permissions d'écriture étendues.
Notre lecture chez CZSyn
Cette découverte de Wiz confirme une tendance que nous observons depuis plusieurs mois en accompagnant nos clients sur leurs usages d'IA en développement : la sécurité d'un agent de codage ne se joue plus seulement dans la qualité de ses réponses, mais dans la fidélité de ce qu'il montre à l'utilisateur avant d'agir. GhostApproval ne casse pas un modèle de langage, elle casse la confiance qu'on accorde à une case à cocher.
Pour une PME française qui laisse un agent IA toucher à des dépôts de production ou à des scripts d'infrastructure, la leçon est directe : un assistant IA de code doit être traité comme n'importe quel outil ayant accès au système de fichiers, avec les mêmes règles de moindre privilège, d'isolation et d'audit qu'un pipeline CI/CD. La réponse divergente d'Anthropic, qui ajoute des mitigations sans reconnaître de vulnérabilité, montre aussi que la frontière entre comportement attendu et faille de sécurité reste floue sur ces outils agentiques. C'est à chaque équipe technique de documenter ses propres règles d'usage plutôt que d'attendre un consensus des éditeurs.
Votre agent IA de code a-t-il les bonnes limites ?
Nous auditons vos usages d'IA en développement (permissions, isolation, sandbox) et sécurisons vos workflows sur-mesure. Audit gratuit sous 24h, dépannage réactif si un incident survient.
29 AVIS 5/5 · +200 PROJETS LIVRÉS · RÉPONSE EXPRESS
Sources primaires
- SecurityWeek, « AI Coding Tools Tricked Into Hacking Developer Machine via Decades-Old Technique ».
- Wiz, éditeur ayant mené la recherche GhostApproval, wiz.io.
- Documentation officielle Claude Code, docs.claude.com/en/docs/claude-code.
