DuneSlide : Deux vulnérabilités RCE critiques liées à une injection de prompt zéro-clic dans l’IDE Cursor ont été découvertes
TL;DR
Cato AI Labs a identifié deux failles critiques permettant l’exécution de code à distance (RCE) dans l’IDE Cursor, un environnement de développement très répandu qui est utilisé par plus de la moitié des entreprises du classement Fortune 500, selon Cursor. Ces deux vulnérabilités RCE, que nous avons baptisées « DuneSlide », ont obtenu un score CVSS de 9,8. Elles permettent de s’échapper de l’environnement sandbox de l’IDE et ont reçues les identifiants CVE CVE-2026-50548 et CVE-2026-50549.
Ensemble, ces vulnérabilités montrent comment l’injection rapide peut aller au-delà de la couche LLM et exposer des vulnérabilités classiques dans des chemins d’exécution de code qui n’étaient traditionnellement pas considérés comme faisant partie de la surface d’attaque.
L’exploitation de l’une ou l’autre de ces vulnérabilités critiques permet à un cybercriminel de remplacer des fichiers système essentiels (tels que le binaire cursorsandbox) et de transformer ainsi les commandes exécutées en mode sandbox en exécutions RCE hors sandbox. Résultat : une compromission totale du système, tant sur la machine hôte que sur les espaces de travail SaaS connectés.
Résumé exécutif
- Découverte des vulnérabilités critiques : Cato AI Labs a identifié deux vulnérabilités distinctes et critiques dans l’IDE Cursor, susceptibles d’entraîner des RCE hors sandbox sur l’ordinateur de l’utilisateur.
- Écriture de fichier arbitraire avec injection de prompt zéro-clic : Ces failles architecturales indépendantes permettent aux cybercriminels d’utiliser des injections de prompts zéro-clic pour écrire des fichiers arbitraires sur le système local du développeur.
- Sandbox Escape et RCE : En tirant parti de ces éléments de base, un cybercriminel peut s’échapper du sandbox du terminal, obtenir ainsi un RCE total et compromettre entièrement le système.
- Vecteur d’attaque zéro-clic : L’exploit ne nécessite aucun droit d’accès préalable ni aucune intervention spécifique de la part de l’utilisateur. Il est déclenché lorsqu’une victime effectue une requête anodine qui, par inadvertance, reçoit une charge utile contrôlée par un cybercriminel provenant d’une source non fiable, telle qu’un serveur MCP ou un résultat de recherche sur Internet.
Présentation technique
Le sandbox Cursor et le vecteur d’attaque
Cursor 2.x est livré par défaut avec une fonctionnalité d’exécution automatique des commandes de terminal au sein d’un sandbox, qui fonctionne sans demander l’autorisation de l’utilisateur. Cette fonctionnalité a été conçue pour éviter une surcharge liée aux approbations, tout en empêchant les cybercriminels de transformer facilement une simple injection de prompt en une attaque RCE.
Vulnérabilité 1 : manipulation des paramètres du répertoire de travail
La première vulnérabilité tient à la manière dont le sandbox définit ses limites de sécurité en fonction des paramètres de l’outil. Lorsqu’une commande exécutée en mode sandbox est exécutée, Cursor met en place une politique de sécurité autorisant les écritures dans le répertoire de travail actuel.
- Alors que le répertoire de travail par défaut pour l’exécution de la commande est défini sur la racine du projet, le paramètre working_directory est un paramètre facultatif de l’outil run_terminal_cmd.
- La faille existe car, lorsque le LLM attribue une valeur non par défaut à ce paramètre, ce chemin d’accès est ajouté sans discernement à la liste des chemins d’accès autorisés en écriture dans le sandbox.
- Une injection de prompt (effectuée via une requête MCP d’apparence inoffensive ou un résultat Web corrompu) peut amener le LLM à définir le paramètre working_directory sur un chemin contrôlé par un cybercriminel, situé en dehors du périmètre du projet.
- En écrivant dans l’exécutable cursorsandbox (/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox), le cybercriminel s’assure que les commandes suivantes s’exécuteront sans les restrictions imposées par le sandbox. Ainsi, les instructions ultérieures issues de la même injection de prompt conduisent à un RCE hors sandbox.
- Les autres chemins vulnérables incluent ~/.zshrc, ~/.zshenv ou ~/Library/LaunchAgents.
Généralement, un attaquant à distance ne peut pas contrôler le répertoire de travail d’une opération exécutée en mode sandbox. Cependant, les agents de codage constituant un logiciel à part entière, dans le cadre de cette vulnérabilité, une injection de ligne de commande sert de passerelle vers cette partie du code.
Vulnérabilité 2 : Échec de la canonicalisation des liens symboliques
La seconde vulnérabilité est totalement indépendante de la première et réside dans les cas limites de résolution des chemins d’accès aux fichiers par Cursor. Elle permet aux cybercriminels de contourner les protections contre les écritures hors limites à l’aide de liens symboliques.
- Une injection de prompt (via une requête MCP inoffensive ou un résultat Web corrompu) peut ordonner à l’agent Cursor de créer un lien symbolique dans le répertoire du projet, pointant vers un fichier situé en dehors de ce répertoire.
- Par défaut, l’agent Cursor tente de canonicaliser les chemins d’accès (en résolvant les liens symboliques) afin de déterminer leur emplacement réel et de vérifier qu’ils se trouvent bien dans la racine du projet.
- La vulnérabilité existe car la logique de canonicalisation comporte un mécanisme de repli dangereux : si elle échoue (par exemple lorsque le chemin n’existe pas ou si l’un de ses répertoires ne dispose pas de droits de lecture), Cursor utilise alors par défaut le lien symbolique d’origine situé dans le répertoire du projet.
- Un acteur malveillant peut alors créer un lien symbolique en écriture seule, forçant ainsi Cursor à considérer que le chemin résolu correspond au chemin du lien symbolique, plutôt qu’au chemin cible. Cela empêche le système de détecter que la destination finale est hors limites, permettant ainsi à l’attaquant de créer à nouveau un lien vers l’exécutable cursorsandbox (/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox).
- En utilisant l’outil Write, le cybercriminel écrase ensuite ce fichier externe via le lien symbolique, neutralisant ainsi le sandbox pour les commandes suivantes exécutées dans le cadre de la même injection de prompt, ce qui aboutit à un RCE.
Dans la plupart des logiciels classiques, un attaquant externe ne peut pas créer à distance des liens symboliques sur la machine de la victime. Dans ce cas, une injection de prompt a transformé l’agent Cursor en une tête de pont permettant de mener des opérations complexes qui ont abouti à la compromission totale du système.
Divulgation responsable
Cato AI Labs s’engage à sécuriser l’écosystème de l’IA et a respecté les pratiques standard en matière de divulgation responsable pour DuneSlide :
- 19 février : les vulnérabilités ont été signalées à l’équipe Cursor.
- 23 février : les vulnérabilités ont été rejetées. La raison : Le modèle de menace de Cursor ne tient pas compte d’une utilisation abusive du serveur MCP, même dans les cas où ce dernier fait l’objet d’une intégration standard et inoffensive, comme l’espace de travail officiel Linear.app.
- 26 février : compte tenu de la gravité de ces deux problèmes, ceux-ci ont été directement signalés à l’équipe de sécurité de Cursor L’équipe de sécurité les a rouverts et a commencé à évaluer les vulnérabilités signalées.
- 1er avril : l’équipe Cursor a confirmé que le correctif concernant la vulnérabilité liée au répertoire de travail serait intégré au client Cursor 3.0 (sorti le 2 avril).
- 1er juin : l’équipe Cursor a confirmé que le correctif de la vulnérabilité liée aux liens cibles avait également été intégré à Cursor 3.0.
- 05 juin : les identifiants CVE CVE-2026-50548 et CVE-2026-50549 ont été attribués, ce qui confirme la gravité critique de ces vulnérabilités.
Conclusion
DuneSlide met en évidence les risques architecturaux spécifiquement liés à la mise à disposition d’environnements d’exécution autonome des commandes pour les LLM. Bien que le sandboxing soit une défense nécessaire, des failles bien distinctes dans la validation des paramètres et dans les cas limites de résolution des chemins d’accès démontrent que les injections de prompt zéro-clic peuvent habilement exploiter des failles logiques isolées pour prendre le contrôle intégral du système. Si ces incidents avaient été des cas isolés de compromission par injection de prompt, nous aurions pu les attribuer à des vulnérabilités spécifiques. Cato AI Labs, cependant, s’emploie toutefois à divulguer de manière responsable les vulnérabilités présentes dans tous les agents de codage populaires, soulignant ainsi la nécessité d’adopter une approche plus systémique en matière de protection. Restez à l’écoute.