DuneSlide : une prompt injection s'échappe du bac à sable de Cursor jusqu'au RCE

De quoi s’agit-il ?

Le 1er juillet 2026, Cato AI Labs (l’équipe d’Itay Ravia, anciennement Aim Security) a publié DuneSlide, deux failles critiques d’exécution de code à distance dans l’éditeur de code assisté par IA Cursor. Toutes deux sont notées 9,8 (CVSS 3.1) et produisent le même effet : elles permettent à un simple prompt d’apparence anodine de s’échapper du bac à sable du terminal de Cursor et d’exécuter des commandes arbitraires sur la machine du développeur. Aucun clic à piéger, aucune fenêtre d’approbation à ignorer — les chercheurs parlent d’attaque « zero-click ».

Le point d’entrée est la prompt injection. L’attaquant ne touche jamais votre Cursor. Il place ses instructions dans un contenu que votre agent lit à votre place — un service connecté via le Model Context Protocol (MCP), ou une page renvoyée par une recherche web — et ces instructions cachées voyagent avec votre question légitime. Cato a signalé les deux problèmes le 19 février 2026 ; ils ont été corrigés dans Cursor 3.0 (sorti le 2 avril), et les identifiants de vulnérabilité ont été attribués le 5 juin. Toutes les versions antérieures à la 3.0 sont concernées. Selon l’éditeur, plus de la moitié des entreprises du Fortune 500 utilisent l’outil.

Comment ça marche

Depuis la branche 2.x, Cursor exécute les commandes du terminal émises par son agent à l’intérieur d’un bac à sable par défaut, sans demande d’approbation — un choix de conception délibéré pour éviter la fatigue d’approbation tout en empêchant qu’une instruction parasite n’endommage la machine. DuneSlide consiste à sortir de cette boîte. Les deux failles suivent le même schéma : amener l’agent à écrire un fichier qu’il ne devrait pas pouvoir écrire, puis se servir de cette écriture pour désactiver le bac à sable. Aucun payload n’est reproduit ici ; le mécanisme est décrit au niveau architectural, conformément à l’analyse de Cato.

La première faille détourne un paramètre d’outil. Le bac à sable de Cursor accorde un accès en écriture au répertoire de travail d’une commande, et ce répertoire est un argument optionnel (working_directory) de l’outil run_terminal_cmd. Lorsque l’agent lui attribue une valeur non par défaut, Cursor ajoute ce chemin à la liste d’écritures autorisées sans la moindre vérification. Des instructions injectées peuvent orienter l’agent vers un fichier système plutôt que vers le projet — par exemple le binaire du bac à sable lui-même (sur macOS, /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox). Une fois ce fichier écrasé, toutes les commandes suivantes s’exécutent sans aucun bac à sable. Les fichiers de démarrage du shell comme ~/.zshrc ou ~/Library/LaunchAgents constituent aussi des cibles.

La seconde faille détourne un contrôle de sécurité. Avant d’écrire, Cursor résout les liens symboliques pour vérifier que la vraie destination se trouve dans le projet. Le bug réside dans le repli : lorsque la canonicalisation échoue — parce que la cible n’existe pas, ou que l’attaquant retire le droit de lecture sur un répertoire du chemin — Cursor abandonne et fait confiance au chemin du lien symbolique resté dans le projet. L’attaquant crée un lien symbolique en écriture seule pointant hors du projet, force l’échec du contrôle, et Cursor écrit directement à travers lui jusqu’au même binaire du bac à sable. Même évasion, autre porte.

La leçon commune : dans un logiciel classique, un attaquant distant ne peut ni définir votre répertoire de travail ni déposer des liens symboliques sur votre disque. Dans un agent de codage, une prompt injection devient le passage vers exactement ces primitives.

Pourquoi c’est important

Une fois le binaire du bac à sable neutralisé, la commande suivante s’exécute en votre nom. C’est le contrôle de la machine du développeur, plus tous les espaces cloud ou SaaS auxquels l’éditeur est connecté — le tout à partir d’un unique prompt d’apparence inoffensive. Aucune exploitation dans la nature n’est constatée ; Cato présente ces travaux comme de la recherche, et le registre public ne fait état d’aucun abus connu à la date de divulgation.

Le point de fond concerne l’emplacement de la vulnérabilité. L’injection n’est que le vecteur de livraison, mais les bugs réels sont classiques : confiance non vérifiée dans un paramètre d’outil, et repli défaillant de la canonicalisation de chemin. La prompt injection a franchi la couche du modèle pour éclairer des chemins de code que personne ne considérait comme faisant partie de la surface d’attaque. C’est aussi la dernière d’une série d’évasions du bac à sable et de la configuration de Cursor (CurXecute, MCPoison, et une faille de Git-hook piégé plus tôt en 2026), chacune contournant un garde-fou différent. Cato indique divulguer des problèmes similaires dans d’autres agents de codage et soutient que le problème est structurel, non une suite de cas isolés.

Défenses

1. Mettez à jour dès maintenant. Passez chaque installation de Cursor en 3.0 ou plus ; les deux failles y sont corrigées et toutes les versions antérieures sont vulnérables. C’est l’action au plus fort impact.
2. Traitez tout contenu lu par l’agent comme non fiable. Les réponses des connecteurs MCP et les résultats de recherche web sont contrôlables par un attaquant. Le modèle de menace initial de Cursor ne couvrait explicitement pas le détournement d’un serveur MCP standard (même l’intégration officielle Linear) — n’héritez pas de cette hypothèse. Restreignez les serveurs MCP accessibles à l’agent et privilégiez les connecteurs en lecture seule ou audités.
3. Protégez les artefacts de la frontière de confiance. Un bac à sable ne vaut que par l’intégrité du binaire qui l’applique. Rendez les binaires du bac à sable, les fichiers de configuration de l’agent et les fichiers de démarrage du shell (~/.zshrc, ~/.zshenv, ~/Library/LaunchAgents) en lecture seule ou sous surveillance d’intégrité, afin qu’une écriture hors périmètre soit détectable même si un garde-fou est contourné.
4. Gardez un humain dans la boucle pour les actions irréversibles. L’exécution automatique sans approbation troque la sûreté contre le confort. Pour un agent opérant sur des entrées non fiables, exigez une confirmation pour toute écriture hors du répertoire du projet et pour toute commande touchant aux composants internes de l’application.
5. Surveillez l’évasion, pas seulement l’injection. Une télémétrie endpoint qui signale les écritures dans les répertoires de ressources de l’application, les nouveaux LaunchAgents ou les modifications des fichiers rc du shell détectera la phase post-injection de cette classe d’attaque, quel que soit le prompt utilisé.
6. Supposez que le schéma se généralise. Tout agent qui lit le web ouvert et peut exécuter des commandes partage cette exposition. Inventoriez votre parc d’agents de codage et appliquez les mêmes contrôles avant la prochaine divulgation.

Status

Élément	Référence	Date	Notes
Divulgation DuneSlide	Cato AI Labs	2026-07-01	Deux failles RCE, CVSS 9,8 (3.1)
Faille du répertoire de travail	CVE-2026-50548	2026-06-05 (ID attribué)	working_directory ajouté à la liste blanche sans validation
Faille de canonicalisation de lien	CVE-2026-50549 / GHSA-3v8f-48vw-3mjx	2026-06-05 (ID attribué)	Le repli fait confiance au chemin du lien resté dans le projet
Signalement à Cursor	Cato AI Labs	2026-02-19	D’abord rejeté le 2026-02-23, rouvert après escalade le 2026-02-26
Correctif livré	Cursor 3.0	2026-04-02	Toutes les versions antérieures à la 3.0 concernées
Exploitation dans la nature	NVD / Cato	2026-07-01	Aucune connue à la date de publication

Le bon cadrage n’est pas « un éditeur IA avait un bug ». C’est que la prompt injection est désormais un moyen fiable d’atteindre des vulnérabilités classiques au sein d’environnements autonomes d’exécution de commandes — et corriger la couche d’injection ne corrige pas les chemins de code qu’elle peut atteindre. Passez en 3.0, puis traitez comme hostile chaque entrée que votre agent lit.