La faille, qui a touché Amazon, Anthropic, Google, Cursor et d’autres, permet à l’agent de donner à l’humain de fausses informations sur lesquelles prendre des décisions.
Une faille de sécurité dans les outils de développement d’IA a permis aux attaquants d’échapper aux bacs à sable en trompant les humains impliqués dans la boucle qui étaient censés approuver sciemment les actions de l’outil, selon le cabinet de recherche en cybersécurité Wiz.
« Nous avons découvert GhostApproval, un modèle de vulnérabilité systématique affectant six des principaux assistants de codage d’IA : Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity et Windsurf (maintenant connu sous le nom de Devin Desktop) », indique le rapport Wiz. « Dans chaque cas, un référentiel malveillant peut inciter l’agent à accéder à des fichiers arbitraires en dehors du sandbox de l’espace de travail, permettant ainsi potentiellement l’exécution de code à distance sur la machine du développeur. »
Le premier rapport sur la faille a été publié plus tôt ce mois-ci par Cato Networks, mais il était limité à une seule plate-forme, Cursor, tandis que Wiz a constaté que son impact était beaucoup plus large.
Le problème de sécurité sous-jacent, à savoir les liens symboliques (symlinks), est bien connu et exploité depuis des décennies. Mais GhostApproval, a noté Wiz, va bien au-delà de leur utilisation historique comme vecteur d’attaque.
Les liens symboliques sont des fichiers spéciaux qui servent de raccourcis vers d’autres fichiers ou répertoires. Lors des attaques, elles visent généralement une cible en dehors de la sphère de contrôle prévue, ce qui permet à un acteur malveillant d’opérer sur des fichiers non autorisés dans un environnement moins ou incontrôlé, en dehors d’un bac à sable sécurisé, ou même d’un système isolé.
« Dans plusieurs cas », a noté Wiz, « le raisonnement interne de l’agent reconnaît explicitement la cible dangereuse, mais l’invite de confirmation présentée à l’utilisateur dissimule entièrement cette information. Il s’agit du CWE-451 – fausse déclaration d’informations critiques dans l’interface utilisateur – superposé à la vulnérabilité du lien symbolique. L’utilisateur approuve ce qu’il considère comme une modification locale inoffensive. L’agent écrit ensuite dans un fichier sensible en dehors de l’espace de travail du projet. «
Wiz a déclaré avoir signalé le problème aux six fournisseurs initialement concernés ; AWS, Cursor et Google « ont résolu le problème rapidement », Augment et Windsurf/Devin « ont accusé réception mais sont restés silencieux », et Anthropic avait déjà résolu le problème avant d’être contacté par Wiz.
Une exposition potentiellement massive
Mais les analystes et les consultants ont déclaré que le problème de l’outil de développement d’IA décrit par Wiz illustre un risque de sécurité bien plus important : les entreprises font beaucoup trop confiance à ces outils et aux informations qu’ils rapportent, ce qui peut offrir une grande opportunité aux attaquants.
Katie Norton, responsable de recherche senior pour DevSecOps chez IDC, a noté que le rapport Wiz soulignait un fait inquiétant. « Le contrôle de sécurité sur lequel les gens s’appuient pour détecter ces actions n’arrête rien. C’est un véritable moyen pour un attaquant de s’introduire dans la machine d’un développeur », a-t-elle déclaré. « La portée est limitée par une condition : l’attaque nécessite qu’un développeur clone et opère sur un référentiel non fiable ou malveillant. Cela concentre le risque dans les flux de travail touchant les contributeurs externes, les référentiels forkés et les dépendances tierces ou open source, plutôt que dans le code créé en interne. »
Norton a déclaré que l’exposition à cette faille, ainsi qu’à des failles similaires dans d’autres outils de développement d’IA, est potentiellement massive. « Depuis mars 2025, les fournisseurs de sécurité et les chercheurs ont révélé des problèmes comparables dans presque tous les principaux assistants de codage d’IA. Ce modèle : une atténuation est introduite, puis un nouveau contournement de cette même atténuation apparaît en quelques mois. Cela mérite d’être surveillé et reflète à quel point le modèle de menace de cette catégorie est encore nouveau à tous les niveaux, il ne s’agit pas d’une lacune spécifique aux pratiques d’un fournisseur donné. «
Cela signifie, dit-elle, que les outils de codage agent nécessitent une défense multicouche, car le risque ne se limite pas au code généré par un agent. « Les outils eux-mêmes font partie de la chaîne d’approvisionnement logicielle et peuvent être attaqués directement. GhostApproval le fait clairement valoir », a-t-elle noté.
« La vulnérabilité n’a rien à voir avec la qualité du code ou une sortie non sécurisée. Il s’agit d’un défaut dans la façon dont l’agent gère les fichiers et représente ses propres actions à l’utilisateur, introduit par la conception de l’outil plutôt que par une mauvaise invite ou une dépendance compromise. L’incapacité à prendre en compte la propre surface d’attaque des outils de codage est ce qui laisse ce type de lacune sans réponse. »
Repenser les politiques et les procédures
Noah Kenney, consultant principal chez Digital 520, est d’accord ; Les RSSI d’entreprise doivent potentiellement repenser bon nombre de leurs politiques et procédures en matière d’outils de développement d’IA.
« Le point important est que le propre raisonnement de l’agent a identifié la cible malveillante et que la boîte de dialogue d’approbation l’a quand même cachée. L’outil savait qu’il écrivait sur des clés SSH et a quand même demandé à un humain d’approuver une modification d’un fichier de configuration, donnant à l’humain une illusion de contrôle sur le modèle », a déclaré Kenney. « Beaucoup considèrent que l’humain dans la boucle est la réponse au risque des agents, mais ce rapport montre que la boucle peut recevoir de mauvaises informations de la part de l’agent même qu’elle est censée superviser. »
Pour cette raison, Kenney a conseillé d’ajuster la manière dont la gestion des outils est appliquée.
« Traitez les assistants de codage IA comme des logiciels privilégiés avec accès au système de fichiers, et non comme des plugins d’éditeur. Cela signifie une discipline en matière de correctifs, l’épinglage de version et la connaissance des outils de votre environnement qui écrivent sur le disque avant autorisation », a déclaré Kenney. « Ensuite, mettez en sandbox le rayon d’explosion. Ces agents doivent s’exécuter sur des référentiels fiables dans des environnements isolés où une écriture ne mène nulle part. Ne comptez pas sur la propre boîte de dialogue de l’outil comme solution de contrôle ou de gouvernance. «
Un problème de conception à l’échelle de la catégorie
Justin Greis, PDG du cabinet de conseil Acceligence, a ajouté que cette faille de sécurité constitue un problème de stratégie de sécurité d’entreprise bien plus important que ne le pensent la plupart des RSSI.
« Six fournisseurs différents sont parvenus indépendamment à un modèle de confiance très similaire. Cela suggère que nous sommes confrontés à un défi de conception à l’échelle d’une catégorie plutôt qu’à une collection de bugs d’implémentation isolés. Si des vulnérabilités comme celle-ci n’étaient pas corrigées, elles représenteraient un risque important pour l’entreprise, en particulier pour les organisations qui permettent aux assistants de codage d’IA d’interagir avec des référentiels ou des environnements de développement de production non fiables », a-t-il déclaré.
« La préoccupation immédiate n’est pas simplement l’exécution de code à distance. Il s’agit plutôt du fait que ces agents fonctionnent avec un niveau d’accès au système de fichiers, d’accès aux outils et de confiance des développeurs que les extensions IDE traditionnelles n’ont jamais eu. Une fois qu’un agent IA devient un participant actif dans le développement logiciel, chaque frontière de confiance qu’il traverse devient une partie de la surface d’attaque de l’organisation. «
