système : OPÉRATIONNEL
← retour à tous les hacks
AGENTS CRITICAL NEW

IDEsaster : quand les fonctions de l'éditeur deviennent des primitives RCE

Ari Marzouk a divulgué une classe de vulnérabilités où l'injection de prompt pousse les agents de code à détourner les fonctions natives de l'éditeur sous-jacent — jusqu'à l'exfiltration et l'exécution de code sur presque tous les IDE IA.

2026-07-03 // 6 min affects: github-copilot, cursor, windsurf, zed, jetbrains-ides, coding-agents

De quoi s’agit-il ?

Le 6 décembre 2025, le chercheur en sécurité Ari « MaccariTA » Marzouk a publié IDEsaster, fruit d’environ six mois d’exploration des éditeurs de code dopés à l’IA. Il ne s’agit pas d’un bug isolé mais d’une classe de vulnérabilités : une injection de prompt qui amène un agent de code à détourner les fonctions natives de l’éditeur sous-jacent — des fonctions antérieures à l’IA, réputées sûres — pour parvenir à l’exfiltration de données et à l’exécution de code à distance.

Les chiffres donnent le ton. Plus de 30 vulnérabilités signalées, 24 identifiants attribués, un bulletin de sécurité AWS et une mise à jour de la documentation de Claude Code reconnaissant le risque. Chaque application testée par Marzouk était vulnérable à la nouvelle chaîne — GitHub Copilot, Cursor, Windsurf, Kiro, Zed, Roo Code, JetBrains Junie, Cline, Gemini CLI, Claude Code et d’autres. Comme la faille réside dans l’éditeur de base partagé plutôt que dans un produit précis, une seule technique compromet tout un écosystème d’un coup.

Comment ça marche

Les attaques antérieures suivaient des chaînes connues : un prompt empoisonné pilote un outil vulnérable, ou pousse des outils ordinaires à modifier les réglages de l’agent (sa config MCP, sa liste d’auto-approbation) pour obtenir l’exécution. IDEsaster ajoute un troisième maillon que la plupart des éditeurs avaient exclu de leur modèle de menace : injection de prompt → outils → fonctions de l’éditeur de base. L’outil d’écriture de fichier de l’agent fait exactement ce pour quoi il est prévu — écrire un fichier — mais ce fichier active une fonction héritée aux effets de bord dangereux. Marzouk illustre trois cas ; aucun prompt d’exploitation n’est reproduit ici, et le chercheur a délibérément retenu les charges exactes tant que certains éditeurs restent non corrigés au-delà des 90 jours.

Le premier cas détourne les schémas JSON distants. De nombreux éditeurs autorisent un fichier .json à référencer un schéma de validation situé à une URL externe, et le récupèrent automatiquement. Un agent poussé à écrire un fichier JSON dont le $schema pointe vers un domaine contrôlé par l’attaquant — avec les données volées ajoutées en paramètre — déclenche la requête tout seul. Fait notable, la récupération se produit même en mode aperçu des différences (diff-preview), contournant certains contrôles humains.

Le deuxième cas est l’écrasement des réglages de l’IDE pour exécuter du code. Contrairement aux rapports antérieurs qui modifiaient un réglage de l’agent, celui-ci vise les réglages de l’éditeur de base, et s’applique donc à tous les produits partageant cet éditeur. Sur les éditeurs dérivés de VS Code, l’agent écrit une charge dans un fichier exécutable toujours présent (un exemple de hook Git, par exemple), puis fait pointer un réglage de chemin de validateur vers lui ; l’ouverture d’un type de fichier correspondant exécute aussitôt le binaire. Les éditeurs JetBrains offrent un chemin équivalent via leur configuration de projet.

Le troisième cas, les espaces de travail multi-racines, montre la profondeur de la classe : un fichier de définition d’espace de travail peut ajouter des dossiers arbitraires comme racines de projet, dissolvant la condition « le fichier doit déjà être dans l’espace de travail » et réactivant l’écrasement de réglages même là où le premier correctif avait été appliqué. On ferme une fonction, une autre apparaît — c’est précisément le propos.

Pourquoi c’est important

Le plafond d’impact est l’exécution de code à distance sur la machine du développeur, plus l’exfiltration silencieuse de tout ce que l’agent peut lire, déclenchée par un contenu que l’agent a simplement traité — un README empoisonné, un fichier de règles, une URL collée avec des caractères invisibles, un serveur MCP compromis. Des millions de développeurs utilisent les produits touchés, et chaque produit testé était exposé. Marzouk attribue la cause racine à un principe de conception manquant qu’il nomme « Secure for AI » : les éditeurs ont été conçus sûrs pour des humains, mais l’ajout d’un agent autonome capable de lire, écrire et exécuter transforme des fonctions héritées bénignes en primitives d’attaque que personne n’a réévaluées. L’injection est inévitable ; le correctif durable consiste à réduire ce qu’un agent détourné a le droit d’atteindre.

Défenses

Pour les développeurs qui utilisent des IDE IA : n’exécutez des agents que sur des projets de confiance, car le contenu des fichiers et même leurs noms sont des vecteurs d’injection ; ne vous connectez qu’à des serveurs MCP de confiance et surveillez leurs changements ; relisez manuellement toute URL ou texte ajouté en contexte à la recherche d’instructions cachées ou invisibles ; et gardez la validation humaine activée partout où l’outil le permet.

Pour les équipes qui construisent des agents : appliquez le moindre privilège à chaque outil — cantonnez read_file à l’espace de travail (pas de traversée, pas de liens symboliques, blocage des dotfiles et des chemins de secrets), limitez write_file aux dossiers sources et exigez une confirmation pour les fichiers de config ou dotfiles, et privilégiez l’approbation humaine ou une liste blanche de domaines pour http_fetch. Supposez la compromission : exigez une confirmation pour toute action sensible, isolez les commandes exécutées (sandbox), et imposez des contrôles d’egress au niveau de l’IDE afin que les effets de bord d’exfiltration (comme une récupération de schéma automatique) soient bloqués globalement. Enfin, intégrez l’ensemble des fonctions de l’éditeur de base au modèle de menace et testez les outils en continu — la surface ne cesse de croître.

Statut

ÉlémentRéférenceNotes
Divulgation IDEsasterAri Marzouk (MaccariTA), 2025-12-0630+ vulns, 24 CVE, principe « Secure for AI »
Schéma JSON distant (exfil)CVE-2025-49150 (Cursor), CVE-2025-53097 (Roo Code), CVE-2025-58335 (Junie)Récupération auto d’une URL $schema contrôlée par l’attaquant
Écrasement des réglages IDE (RCE)CVE-2025-53773 (Copilot), CVE-2025-54130 (Cursor), CVE-2025-53536 (Roo Code), CVE-2025-55012 (Zed)Un réglage de l’éditeur de base pointe un validateur vers un exécutable planté
Espace de travail multi-racines (RCE)CVE-2025-64660 (Copilot), CVE-2025-61590 (Cursor), CVE-2025-58372 (Roo Code)Le fichier d’espace de travail ajoute des racines arbitraires, supprimant les préconditions
Reconnaissances éditeursAWS-2025-019 ; doc Claude Code mise à jourCertains produits corrigés sans CVE ; quelques-uns non corrigés au-delà de 90 jours
Exploitation observéeSelon le chercheur, à la divulgationAucune signalée ; charges retenues pour protéger les utilisateurs

La leçon dépasse le cas des éditeurs : tout agent autonome greffé sur un logiciel qui le précède hérite de chacune de ses fonctions comme primitive potentielle. L’injection de prompt est le vecteur de livraison inévitable — la défense consiste à supposer qu’elle réussit et à contraindre ce que l’agent peut faire ensuite.

Sources