DuneSlide : l'injection de prompt s'évade du sandbox de Cursor jusqu'au RCE système
Cato AI Labs (1er juillet 2026) montre qu'un simple prompt piégé — via un serveur MCP ou un résultat web — peut écraser le binaire de sandbox de Cursor et aboutir à un RCE système zéro-clic. Corrigé dans Cursor 3.0.
De quoi s’agit-il ?
Le 1er juillet 2026, Cato AI Labs (Itay Ravia) a publié DuneSlide : Two Critical RCE Vulnerabilities via Zero-Click Prompt Injection in Cursor IDE. L’article décrit deux failles indépendantes de l’éditeur de code Cursor — un outil que Cursor dit utilisé par plus de la moitié du Fortune 500 — qui permettent à un prompt d’apparence anodine de s’évader du sandbox de commandes de l’éditeur et d’exécuter du code arbitraire sur la machine du développeur. Les deux failles sont notées 9,8/10 et corrigées dans Cursor 3.0 (publié le 2 avril 2026) ; toutes les versions antérieures sont affectées. La recherche est présentée dans une optique défensive, sans exploitation observée dans la nature.
Le déclencheur est l’injection indirecte de prompt : l’attaquant n’écrit jamais dans votre éditeur. Il place des instructions dans un contenu que votre agent lit pour vous — un service connecté via le Model Context Protocol (MCP) ou une page renvoyée par une recherche web — et une question ordinaire entraîne avec elle les instructions cachées. Aucun clic, aucune boîte de validation : d’où le « zéro-clic ». L’aspect marquant de DuneSlide tient à la cible : l’injection de prompt dépasse la couche du modèle et réactive de classiques failles d’écriture de fichier dans des chemins de code que personne ne considérait comme accessibles à un attaquant.
Comment ça marche
La branche 2.x de Cursor exécute par défaut les commandes de l’agent dans un sandbox, sans demander la validation de chacune — un compromis assumé contre la fatigue liée aux approbations. 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 sandbox. La cible de choix sur macOS est le binaire de sandbox lui-même (l’exécutable cursorsandbox dans le bundle de l’application) ; une fois écrasé, toute commande ultérieure s’exécute sans confinement.
La première faille exploite un paramètre d’outil. Lors de l’exécution d’une commande sandboxée, Cursor construit une politique autorisant les écritures dans le dossier de travail de la commande — or working_directory est un paramètre optionnel de l’outil run_terminal_cmd. Lorsque le modèle lui affecte une valeur non par défaut, ce chemin est ajouté à la liste d’écriture autorisée sans validation ; des instructions injectées peuvent donc le pointer vers un fichier système plutôt que vers le projet. Des fichiers de démarrage comme ~/.zshrc ou ~/Library/LaunchAgents sont des cibles tout aussi viables.
La seconde faille est un défaut de canonicalisation de lien symbolique, indépendant de la première. Avant d’écrire, Cursor résout les liens symboliques pour vérifier que la destination réelle se trouve dans la racine du projet. Le problème est le repli : quand la canonicalisation échoue — parce que la cible n’existe pas, ou que l’attaquant retire le droit de lecture sur un dossier du chemin — Cursor fait confiance au chemin symbolique interne au projet au lieu de refuser l’écriture. Un lien symbolique en écriture seule pointant hors du projet passe donc le contrôle, et l’écriture atteint malgré tout le binaire de sandbox. Même évasion, autre porte. Aucun code d’exploitation fonctionnel n’est reproduit ici ; le mécanisme est décrit au niveau que la divulgation a déjà rendu public.
Exemple de prompt
Un schéma défensif et non actionnable de l’évasion DuneSlide. Les charges sont caviardées — il montre pourquoi la frontière de confiance cède, pas comment la reproduire.
# DuneSlide: prompt injection escapes Cursor's sandbox (illustrative, defensive)
# Zero-click indirect injection arrives via an MCP result or fetched web page:
hidden = "[hidden instruction in untrusted content]"
# It steers run_terminal_cmd's OPTIONAL working_directory outside the project,
# silently widening the sandbox write allowlist a model-set arg controls:
run_terminal_cmd(working_directory="[system path]", command="[REDACTED]")
# -> next command runs unconfined -> OS-level RCE as the developer.
# Defense: upgrade to Cursor 3.0; derive sandbox scope from trusted policy,
# not tool args; canonicalize symlinks and FAIL CLOSED; block writes to binaries.
Pourquoi c’est important
C’est le trio létal matérialisé à l’intérieur d’un outil de développement : l’agent détient une autorité réelle (écriture de fichiers locaux, exécution de commandes, sessions cloud connectées), il ingère du contenu non fiable, et les deux se rejoignent sans intervention humaine. Une fois le binaire de sandbox écrasé, la commande suivante s’exécute en votre nom — contrôle complet du poste, plus tout espace de travail SaaS ou cloud auquel l’éditeur est authentifié. Et le point d’entrée est banal : un résultat piégé provenant d’une intégration MCP standard et anodine suffit — précisément le cas que Cursor estimait d’abord hors de son modèle de menace.
DuneSlide n’est pas un cas isolé. Il s’inscrit dans une série documentée de failles Cursor qui partent d’un prompt piégé pour aboutir à l’exécution de code, chacune contournant un garde-fou différent — le même schéma injection de prompt vers RCE observé dans les frameworks d’agents, et proche des évasions d’approbation par lien symbolique dans les agents de code. Cato indique divulguer des failles similaires dans d’autres agents de code et soutient que le problème est structurel, et non une suite de bugs sans lien.
Défenses
- Mettez à jour maintenant. Les deux problèmes sont corrigés dans Cursor 3.0. La mise à niveau est l’action la plus efficace ; toutes les versions antérieures à 3.0 sont vulnérables.
- Ne laissez pas un paramètre d’outil redessiner la frontière de sécurité. La cause profonde de la première faille est qu’un argument contrôlé par le modèle (
working_directory) a élargi en silence la liste d’écriture. La portée du sandbox doit découler d’une politique de confiance, jamais de paramètres que le LLM peut fixer — traitez tous les arguments d’outil comme des entrées non fiables. - Canonicalisez les chemins de façon sûre et échouez en mode fermé. Résolvez les liens symboliques avant toute écriture et refusez en cas d’échec de la résolution, plutôt que de retomber sur le chemin interne non résolu. Appliquez la frontière de la racine du projet à la cible finale, et interdisez l’écriture vers les exécutables, bundles d’application et fichiers de démarrage du shell, quel que soit le chemin employé.
- Contraignez la source de l’injection. L’exécution automatique des commandes de l’agent sur du contenu tiré de serveurs MCP ou de recherches web est le déclencheur. Placez les actions irréversibles ou hors projet derrière une validation, et appliquez la règle de deux des agents afin qu’un contenu ingéré depuis une source non fiable ne puisse pas piloter directement des écritures de fichier privilégiées.
- Considérez l’éditeur comme un point d’entrée accessible. Exécutez les agents de code au moindre privilège, restreignez la portée de leurs identifiants, et surveillez les écritures vers les binaires de sandbox et les fichiers de démarrage — la signature d’une tentative d’évasion.
Statut
| Élément | Référence | Date | Notes |
|---|---|---|---|
| Divulgation DuneSlide | Cato AI Labs (Itay Ravia) | 2026-07-01 | Deux failles RCE indépendantes ; CVSS 9,8 ; recherche, pas d’exploitation active |
| Écriture via working directory | CVE-2026-50548 | 2026-06-05 (ID attribué) | Paramètre de run_terminal_cmd ajouté à la liste d’écriture du sandbox |
| Canonicalisation de lien symbolique | CVE-2026-50549 | 2026-06-05 (ID attribué) | Repli permissif faisant confiance au chemin symbolique interne |
| Signalement à Cursor | Chronologie Cato | 2026-02-19 | D’abord rejeté (hors modèle de menace), puis re-trié |
| Correctif livré | Cursor 3.0 | 2026-04-02 | Toutes les versions antérieures à 3.0 affectées |
La leçon durable est celle des auteurs : donner à un LLM l’exécution autonome de commandes transforme chaque endroit où un paramètre d’agent ou un nom de fichier résolu franchit une frontière de confiance en surface d’attaque. Le sandbox est nécessaire mais insuffisant — la frontière doit être appliquée sur une politique de confiance et sur la cible finale résolue, non sur des valeurs que l’on peut convaincre le modèle de fournir.
Sources
- → https://www.catonetworks.com/blog/duneslide-two-critical-rce-vulnerabilities/
- → https://thehackernews.com/2026/07/critical-cursor-flaws-could-let-prompt.html
- → https://www.securityweek.com/critical-cursor-ai-ide-flaws-could-lead-to-os-level-remote-code-execution/
- → https://nvd.nist.gov/vuln/detail/CVE-2026-50548
- → https://nvd.nist.gov/vuln/detail/CVE-2026-50549