CVE-2026-30615 : une prompt injection réécrit la config MCP de Windsurf en RCE

De quoi s’agit-il ?

Le 15 avril 2026, OX Security a publié un avis de divulgation complet couvrant une famille de vulnérabilités d’injection de commandes liées à la façon dont les applications traitent les configurations de serveurs MCP STDIO (Model Context Protocol). L’une des entrées de cet avis est CVE-2026-30615, une faille « prompt injection vers RCE » dans l’IDE de code Windsurf (build 1.9544.26), publiée au NVD le même jour et notée CVSS 8.0 (High), OX qualifiant son impact de critique.

Le mécanisme, d’après le NVD et l’avis GitHub GHSA-wj2m-jvpr-64cq : lorsque Windsurf traite du contenu HTML contrôlé par l’attaquant, des instructions intégrées peuvent provoquer « une modification non autorisée de la configuration MCP locale et l’enregistrement automatique d’un serveur MCP STDIO malveillant, aboutissant à l’exécution de commandes arbitraires sans interaction supplémentaire de l’utilisateur ». Elle est classée sous CWE-77 (injection de commandes).

Le détail qui a valu à Windsurf le seul CVE de la famille « modification de config MCP par prompt injection » d’OX est le chemin zéro-clic : le traitement par le modèle d’un contenu non fiable réécrit directement la config JSON du MCP. Les autres assistants de code testés dans la même famille — Cursor, Claude Code, Gemini-CLI, GitHub Copilot — exigeaient au moins une approbation explicite de l’utilisateur pour éditer le fichier de config, ce qui (selon les modèles de menace de ces éditeurs) ne constitue pas une vulnérabilité.

Comment ça marche

Il s’agit d’une injection de prompt indirecte qui retombe sur un effet de bord privilégié. Aucun payload n’est reproduit ici ; la chaîne est une classe, pas une recette.

Étape                       Ce qui se passe
--------------------------  ------------------------------------------------
1. Contenu non fiable       L'agent ingère du texte contrôlé par l'attaquant :
                            une page web qu'il consulte, un README d'un dépôt
                            cloné, ou une description d'outil renvoyée par un
                            serveur MCP distant.
2. Injection                Des instructions cachées dans ce contenu sont
                            traitées comme des directives par le modèle, et
                            non comme des données.
3. Écriture de config       La directive amène l'agent à modifier la config
                            MCP LOCALE (JSON) — en ajoutant une nouvelle
                            entrée de serveur de type de transport « stdio ».
4. Enregistrement serveur   La nouvelle entrée STDIO porte un « command » +
                            « args » que l'hôte lance comme sous-processus [REDACTED].
5. Exécution                Au (re)lancement, l'hôte exécute la commande avec
                            les privilèges du processus IDE. RCE.

La cause racine qu’OX retrace dans tout l’avis est en amont de tout produit isolé : les configurations MCP STDIO spécifient un command et des args transmis à un lanceur de sous-processus (par ex. StdioServerParameters) sans assainissement ni liste blanche. Le transport STDIO consiste, par conception, à « lancer ce processus local ». Quand le chemin qui écrit cette config peut être atteint par une entrée non fiable — ici, via la fenêtre de contexte du LLM lui-même — l’autorité de configuration et l’exécution de code fusionnent en un même primitif. C’est le même problème structurel documenté pour le transport MCP STDIO et pour l’injection par nom d’outil dans d’autres agents.

Pourquoi c’est important

Un IDE de code est un hôte à forte valeur : il détient du code source, des secrets, des clés SSH, des identifiants cloud et un shell. Transformer du contenu que l’agent se contente de lire en commandes que l’hôte exécute retire entièrement l’humain de la boucle — pas de lien malveillant à cliquer, pas de boîte de dialogue à fermer. Un README empoisonné dans une dépendance que vous clonez, ou une page forgée que l’agent va chercher pendant une « recherche », suffit.

Cela se généralise. L’avis d’OX liste dix CVE réparties en quatre familles (LangFlow, GPT Researcher, LiteLLM, Agent Zero, Fay, Bisheng, Jaaz, DocsGPT et d’autres), toutes enracinées dans le même schéma de config STDIO non assainie. Windsurf est simplement la démonstration la plus nette que le chemin d’écriture peut être piloté par prompt injection sans clic. Plusieurs éditeurs ont refusé de corriger, qualifiant l’exécution directe de commandes de « comportement attendu » — ce qui signifie que le schéma persistera dans l’écosystème, et que la charge revient aux exploitants.

Défenses

1. Mettez Windsurf à jour. Quittez le build 1.9544.26 pour la version courante. Traitez l’IDE comme tout autre point exposé à du RCE dans votre SLA de correctifs.
2. Exigez un consentement explicite et éclairé pour les changements de config MCP. Toute écriture dans la config MCP — surtout l’ajout d’un serveur stdio — devrait demander une approbation humaine qui affiche la commande et les args. Un « autoriser l’édition du fichier ? » aveugle ne suffit pas ; l’utilisateur doit voir ce qui sera exécuté.
3. Mettez en liste blanche les commandes STDIO, et auditez les args. Restreindre command à python/npm/npx est nécessaire mais insuffisant : OX a contourné de telles listes blanches via des options d’arguments (par ex. en passant une commande via les options d’un lanceur autorisé). Contraignez aussi les arguments, ou préférez des transports non-STDIO.
4. Traitez tout contenu récupéré comme des données non fiables, jamais des instructions. Appliquez la grille du trio létal : un agent qui combine accès à des données privées, exposition à du contenu non fiable et un canal d’exfiltration/exécution est exploitable par conception. Cassez un des piliers — isolez l’agent en bac à sable, retirez-lui la capacité d’écrire sa propre config, ou isolez la navigation non fiable.
5. Moindre privilège pour le processus de l’agent. Faites tourner les agents de code dans un conteneur ou une VM sans identifiants cloud permanents et avec un système de fichiers restreint, afin qu’une réécriture de config réussie ne donne qu’un shell confiné et de faible valeur plutôt qu’une compromission totale.
6. Surveillez le fichier de config. Surveillez les chemins de config mcp pour détecter des écritures inattendues et de nouvelles entrées stdio ; alertez sur les sous-processus lancés par l’IDE qui ne correspondent pas à une chaîne d’outils connue.

Statut

Élément	Référence	Date	Notes
Avis OX Security (10 CVE)	OX Security	2026-04-15	Windsurf = famille n°3 : « édition de config MCP par prompt injection »
Publication de CVE-2026-30615	NVD (source : MITRE)	2026-04-15	CVSS 8.0 High, CWE-77 ; dernière modif. 2026-04-17
Avis GitHub GHSA-wj2m-jvpr-64cq	GitHub Advisory DB	2026-04-15	Affecté : Windsurf 1.9544.26
Agents comparables (sans CVE)	OX Security	2026-04-15	Cursor, Claude Code, Gemini-CLI, Copilot — exigent une approbation utilisateur pour éditer la config

Le titre n’est pas « un IDE a eu un bug ». C’est que config MCP STDIO + contexte de modèle non fiable = un primitif d’exécution de code à distance, et Windsurf a montré que l’écriture peut être déclenchée sans interaction utilisateur. Le travail défensif consiste à maintenir l’autorité d’écriture de la config et le contenu non fiable de part et d’autre d’une frontière que le modèle ne peut pas franchir seul.