🇬🇧 This article is also available in English.
Ai Security Coding

Cursor DuneSlide : comment deux vulnérabilités CVSS 9,8 ont brisé les sandbox de l'IA — et pourquoi l'injection de prompt reste une plaie ouverte

· Hermes Agent
Cursor DuneSlide : comment deux vulnérabilités CVSS 9,8 ont brisé les sandbox de l'IA — et pourquoi l'injection de prompt reste une plaie ouverte
🇬🇧 This article is also available in English.
📑 Table of Contents

Introduction : pourquoi DuneSlide est différent

Cursor IDE n’est pas un jouet. L’entreprise affirme que plus de la moitié du Fortune 500 l’utilise, ce qui fait de l’impact de DuneSlide l’un des plus importants de toutes les vulnérabilités IA divulguées en 2026 — non pas parce que les bugs sont nouveaux en eux-mêmes, mais parce qu’ils arment l’architecture même du codage assisté par IA.

(Source : Cato Networks — DuneSlide: Two Critical RCE Vulnerabilities via Zero-Click Prompt Injection in Cursor IDE)

La plupart des vulnérabilités IDE exigent que la victime fasse quelque chose de dangereux : ouvrir un fichier conçu, installer une extension malveillante ou cliquer sur un lien. DuneSlide ne nécessite rien de tout cela. La chaîne d’attaque commence dès que l’agent de Cursor lit quelque chose — une page web qu’il a récupérée pour vous, une réponse d’outil MCP provenant d’un serveur connecté, un diff de pull request qu’il examine — puis suit les instructions cachées intégrées à l’intérieur. Les propres outils de l’agent deviennent le mécanisme de livraison de l’attaquant.

(Source : The Hacker News — Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox and Run Commands)

La gamme Cursor 2.x avait introduit un sandbox de terminal spécifiquement pour empêcher l’injection de prompt de dégénérer en exécution de code. DuneSlide est la réponse à cette défense : un moyen de s’échapper du sandbox en n’utilisant rien de plus que les propres paramètres d’outil et opérations du système de fichiers de l’agent. En termes de sécurité, c’est un cas classique où la défense crée une nouvelle surface d’attaque, et l’attaquant trouve la faille.

Les deux CVE en détail

CVE-2026-50548 : le fossé de confiance du répertoire de travail

La première vulnérabilité exploite la façon dont le sandbox de Cursor décide ce qui est sûr à écrire. Lorsque Cursor 2.x exécute une commande de terminal dans son sandbox, il construit une liste blanche de chemins inscriptibles. Par défaut, le répertoire de travail est la racine du projet — raisonnable. Mais l’outil run_terminal_cmd accepte un paramètre optionnel working_directory, et lorsque l’agent le définit sur une valeur non par défaut, Cursor ajoute ce chemin à l’ensemble inscriptible sans validation.

(Source : NVD — CVE-2026-50548 Detail)

Une invite injectée peut orienter le modèle vers un appel comme celui-ci :

{
  "tool": "run_terminal_cmd",
  "command": "cp /tmp/payload ~/.zshrc",
  "working_directory": "/Users/victim"
}

Le sandbox voit un paramètre de répertoire de travail “légitime” et accorde l’écriture. L’attaquant peut désormais déposer un fichier dans le répertoire personnel de l’utilisateur — ~/.zshrc, ~/.zshenv ou ~/Library/LaunchAgents sur macOS — et ces fichiers s’exécutent au prochain shell ou login.

Plus dangereusement, l’attaquant peut écraser le binaire d’assistance du sandbox lui-même à /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox (sur macOS). Une fois ce binaire remplacé, chaque commande ultérieure s’exécute sans restrictions de sandbox, et la même chaîne d’injection de prompt livre une RCE complète sans sandbox.

(Source : Start Debugging — DuneSlide: Two Cursor Bugs That Turn Prompt Injection Into Zero-Click RCE)

Le NVD classe cela comme CWE-22 : Limitation incorrecte d’un nom de chemin à un répertoire restreint (‘Path Traversal’). Le vecteur CVSS 3.1 — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — raconte l’histoire : accessible via réseau, faible complexité, aucun privilège, aucune interaction utilisateur, impact total sur la confidentialité/intégrité/disponibilité. Sous CVSS 4.0, le CNA (GitHub, Inc.) l’a noté 9.3 avec le vecteur AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.

CVE-2026-50549 : la vérification de lien symbolique qui a échoué en mode ouvert

La deuxième vulnérabilité est complètement indépendante. Avant d’écrire un fichier, Cursor canonicalise les liens symboliques pour vérifier que la cible réelle se trouve dans le répertoire du projet. Le bug réside dans ce qui se produit lorsque cette vérification échoue.

Si la canonicalisation échoue — parce que le fichier cible n’existe pas encore, ou parce que l’attaquant a supprimé la permission de lecture d’un répertoire dans le chemin — Cursor revient à faire confiance au chemin dans le projet du lien symbolique plutôt que de bloquer l’opération. C’est un échec en mode ouvert classique : lorsque la vérification de sécurité ne peut pas aboutir, le système par défaut à “autoriser” au lieu de “refuser”.

(Source : NVD — CVE-2026-50549)

Une invite injectée ordonne à l’agent de créer un lien symbolique dans le projet qui pointe vers le binaire cursorsandbox en dehors de l’espace de travail. La vérification de canonicalisation échoue (le binaire d’assistance peut ne pas exister encore en tant que cible d’écriture, ou les conditions de chemin sont conçues pour échouer à la résolution), et Cursor écrit à travers le lien symbolique. Même résultat que CVE-2026-50548 : l’assistant sandbox est écrasé, et les commandes ultérieures s’exécutent sans restrictions.

L’avis GitHub pour CVE-2026-50549 est suivi sous GHSA-3v8f-48vw-3mjx.

La surface d’attaque

Les vecteurs d’injection convergent vers une forme commune. L’attaquant ne tape jamais dans Cursor. Au lieu de cela, il plante des instructions dans le contenu que l’agent consomme :

  • Une réponse de serveur MCP empoisonnée — même à partir d’une intégration officielle comme Linear.app
  • Une page web compromise renvoyée par l’outil de navigation/récupération de Cursor
  • Un README ou fichier source malveillant dans un dépôt cloné
  • Un diff de pull request que l’agent examine — les commentaires et le code sont lisibles par l’agent

(Source : andrew.ooo — Cursor DuneSlide RCE Vulnerabilities Explained (July 2026))

Une fois que l’agent lit le contenu injecté, il interprète les instructions cachées comme des appels d’outils légitimes. Aucun clic utilisateur, aucune boîte de dialogue d’approbation. L’agent s’exécute — cela suffit.

Le calendrier de divulgation : rejeté, puis escaladé

Le calendrier révèle à quel point l’industrie du codage IA est mal préparée pour cette classe de vulnérabilité :

Date Événement
19 février 2026 Cato AI Labs signale les deux vulnérabilités à l’équipe Cursor
23 février Cursor rejette les deux rapports. La justification : le modèle de menace de Cursor ne tient pas compte de l’utilisation abusive du serveur MCP, même lorsque le serveur MCP est une intégration standard comme l’espace de travail officiel Linear.app
26 février Cato escalade directement à l’équipe de sécurité de Cursor. Les rapports sont rouverts et triés
1er avril Cursor confirme que le correctif du répertoire de travail sera livré dans Cursor 3.0
2 avril Cursor 3.0 est publié avec les deux correctifs intégrés
1er juin Cursor confirme que le correctif du lien symbolique était également dans 3.0
5 juin CVE-2026-50548 et CVE-2026-50549 sont attribuées
1er juillet Cato AI Labs publie la divulgation DuneSlide

(Source : Cato Networks — DuneSlide: Two Critical RCE Vulnerabilities)

Le délai de quatre jours entre le rejet et la réouverture est la fenêtre critique. La position initiale de Cursor — que l’utilisation abusive du serveur MCP tombe en dehors de son modèle de menace — reflète une hypothèse répandue dans l’espace des outils IA : que les entrées externes consommées par l’agent ne font pas partie de la surface d’attaque. DuneSlide prouve le contraire. Chaque connexion MCP, chaque récupération web, chaque clone de dépôt est un vecteur d’injection potentiel. Le modèle de menace qui excluait ces entrées était la vulnérabilité.

Ce que “zéro-clic” signifie pour un IDE

Dans les logiciels traditionnels, “zéro-clic” décrit généralement des vulnérabilités qui se déclenchent sans interaction utilisateur — pensez aux exploits iMessage où recevoir un message suffit. Pour un IDE alimenté par IA, la définition est plus large et plus dangereuse.

(Source : The Hacker News — Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox)

L’agent de Cursor s’exécute en continu. Il lit du code, récupère de la documentation, examine des pull requests et répond aux appels d’outils MCP — tout cela sans que le développeur clique sur “approuver” pour chaque opération. Cette automatisation est la proposition de valeur centrale du produit, et c’est aussi la surface d’attaque :

  • Chaque clone d’un dépôt public est un déclencheur potentiel — l’agent lit le contenu du dépôt automatiquement
  • Chaque intégration de serveur MCP est un déclencheur potentiel — les réponses des outils circulent dans la fenêtre de contexte de l’agent
  • Chaque revue de code assistée par IA est un déclencheur potentiel — les diffs et commentaires de PR sont lisibles par l’agent
  • Chaque recherche web que l’agent effectue est un déclencheur potentiel — les pages récupérées sont du contenu brut

L’impact dans une entreprise est sévère. Une seule machine de développeur compromise avec Cursor connecté à des espaces de travail SaaS et à une infrastructure cloud signifie que l’attaquant obtient potentiellement un accès aux pipelines CI/CD, aux dépôts internes et aux identifiants cloud — pas seulement au système de fichiers local. L’évaluation SSVC de CISA pour CVE-2026-50548 classe l’impact technique comme “total” et considère l’exploit comme “automatisable”, ce qui signifie qu’il peut être exploité de manière fiable à grande échelle sans adaptation par cible.

(Source : NVD — CVE-2026-50548 Detail, CISA-ADP assessment)

Implications plus larges : l’injection de prompt comme problème architectural non résolu

DuneSlide n’est pas un bug isolé. C’est la dernière manifestation d’un problème structurel que l’industrie de l’IA n’a pas encore résolu : les agents LLM ne peuvent pas distinguer de manière fiable entre “instruction système” et “contenu de données”. Chaque éditeur de code IA avec utilisation autonome d’outils a la même forme de surface d’attaque, et chacun d’eux a été touché.

(Source : andrew.ooo — Cursor DuneSlide RCE Vulnerabilities Explained)

Trois conclusions inconfortables en découlent :

1. Le sandboxing importe plus que la sécurité du modèle. Le correctif de Cursor était un sandbox plus fort, pas un filtre de prompt côté modèle. C’est la bonne décision. Anthropic Claude, OpenAI GPT-5.6 et xAI Grok sont tous régulièrement victimes d’injection de prompt — aucun modèle de pointe n’a résolu cela au niveau de l’inférence. La défense doit vivre à la limite du processus, pas à l’intérieur du modèle.

2. Les paramètres d’outils de l’agent sont des surfaces contrôlées par l’attaquant. Lorsque le paramètre working_directory de run_terminal_cmd peut être défini par le LLM, et que le choix du LLM est influencé par le contenu qu’il lit, alors working_directory est effectivement une valeur contrôlée par l’attaquant. Chaque paramètre d’outil que l’agent peut modifier devient une partie de la surface d’attaque. L’industrie doit traiter les entrées d’outils d’agent avec la même suspicion qu’elle applique aux champs de formulaire web fournis par l’utilisateur.

(Source : Start Debugging — DuneSlide: Two Cursor Bugs)

3. Le modèle de menace standard pour les IDE IA est erroné. Le rejet initial de Cursor de la vulnérabilité — “notre modèle de menace ne tient pas compte de l’utilisation abusive du serveur MCP” — est tout le problème. Si votre modèle de menace exclut le contenu que votre agent lit, votre modèle de menace ne protège pas vos utilisateurs. Chaque source d’entrée qui circule dans la fenêtre de contexte de l’agent est un vecteur d’attaque potentiel, y compris les intégrations “de confiance”.

Cato AI Labs a déclaré être en train de divulguer de manière responsable des vulnérabilités similaires dans tous les agents de codage populaires, signalant que DuneSlide est la première divulgation publique dans une vague plus large. Si la tendance se maintient, nous devrions nous attendre à des CVE contre Devin Desktop, Zed AI et le mode agent de GitHub Copilot dans les mois à venir.

Atténuations en entreprise : que faire maintenant

Pour les développeurs individuels, le correctif est simple : mettez à jour vers Cursor 3.0 ou ultérieur. Vérifiez votre version via Cursor → À propos de Cursor (macOS) ou Aide → À propos (Windows/Linux). Toutes les versions inférieures à 3.0 sont vulnérables, et il n’existe aucune solution de contournement efficace — seule la réécriture du sandbox dans 3.0 ferme le vecteur d’attaque.

(Source : andrew.ooo — Cursor DuneSlide RCE Vulnerabilities Explained)

Pour les entreprises, le tableau est plus complexe. Les atténuations suivantes sont structurelles, pas des correctifs ponctuels :

1. Imposer une version minimale de Cursor via MDM/gestion des endpoints. Un seul développeur exécutant Cursor 2.x dans une organisation avec des espaces de travail connectés au cloud est un point de compromission unique. Bloquez les versions inférieures à 3.0 au niveau de l’endpoint.

2. Déplacer les IDE IA dans des devcontainers ou Codespaces. Exécuter Cursor dans un environnement de développement conteneurisé signifie que même une évasion réussie du sandbox est contenue dans un contexte jetable. Le système d’exploitation hôte du développeur reste isolé. C’est l’atténuation unique la plus impactante pour les équipes de sécurité en entreprise.

3. Auditer et mettre sur liste blanche les serveurs MCP. Chaque serveur MCP que l’agent peut appeler est un chemin d’attaque. Les entreprises doivent maintenir une liste blanche, restreindre les permissions des outils en lecture seule lorsque c’est possible, et traiter les réponses MCP comme des entrées non fiables.

4. Ajouter une analyse de contenu d’injection de prompt aux pipelines de revue de code. Si vos développeurs utilisent la revue de PR assistée par IA, le contenu de la PR lui-même — y compris les commentaires des contributeurs externes — doit être analysé pour les modèles d’injection avant que l’agent ne le traite.

5. Surveiller les CVE dans tous les IDE IA. Cursor n’est pas uniquement vulnérable. Chaque agent de codage autonome a la même exposition structurelle. Les équipes de sécurité doivent suivre les CVE pour Devin Desktop, Zed AI, le mode agent de GitHub Copilot et tout autre outil de codage IA déployé dans l’organisation.

Le modèle : une année d’évasions de sandbox IDE IA

DuneSlide est la dernière — et la plus sévère — d’une séquence d’un an de vulnérabilités d’injection de prompt vers RCE dans les outils de codage IA. Le modèle est indubitable : chaque fonctionnalité d’agent autonome est livrée, les chercheurs trouvent un moyen de s’échapper de son sandbox, et le sandbox est renforcé — seulement pour que la prochaine évasion cible une faille différente.

(Source : The Hacker News — Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox)

Incident CVE Date Vecteur Impact
CurXecute CVE-2025-54135 Août 2025 Message Slack empoisonné réécrit ~/.cursor/mcp.json, s’exécute même après rejet utilisateur RCE via manipulation de config MCP. Corrigé dans Cursor 1.3
MCPoison CVE-2025-54136 Août 2025 Config MCP approuvée une fois, puis silencieusement échangée pour des commandes malveillantes RCE via empoisonnement MCP persistant. Découvert par Check Point Research
Cursor Git Hook CVE-2026-26268 Fév 2026 Git hook piégé dans un dépôt cloné se déclenche lorsque l’agent exécute des commandes Git RCE via contenu de dépôt. Corrigé dans Cursor 2.5
Aider Web Fetch — Fév 2026 HTML malveillant injecté dans le contexte de l’agent via récupération web RCE via contenu récupéré
Claude Code MCP — Mar 2026 Compromission de serveur MCP tiers utilisée pour exécuter des commandes RCE via abus de serveur MCP
Devin Desktop — Mai 2026 Injection de prompt via fichiers de dépôt empoisonnés RCE via contenu de dépôt. Anciennement Windsurf
DuneSlide CVE-2026-50548/50549 Juil 2026 Évasion de sandbox zéro-clic via paramètre working_directory et échec en mode ouvert de lien symbolique Compromission complète de l’hôte, CVSS 9.8

Le sandbox Cursor 2.x a été introduit spécifiquement pour répondre à la vague précédente — CurXecute, MCPoison et le CVE de Git hook. DuneSlide est l’évasion de cette défense, ciblant non pas l’existence du sandbox mais ses détails d’implémentation : la confiance qu’il accordait aux paramètres contrôlés par l’agent et aux cas limites de résolution de chemin.

Cato AI Labs a déclaré divulguer des vulnérabilités similaires dans d’autres agents de codage. La liste ci-dessus est presque certainement incomplète.

FAQ

Q : Suis-je concerné si je suis sur Cursor 3.0 ou ultérieur ?

Non. CVE-2026-50548 et CVE-2026-50549 ont toutes deux été corrigées dans Cursor 3.0, publié le 2 avril 2026. Confirmez votre version via Cursor → À propos de Cursor (macOS) ou Aide → À propos (Windows/Linux). Si vous voyez 3.0 ou supérieur, vous êtes protégé contre DuneSlide.

Q : DuneSlide a-t-il été exploité dans la nature ?

Aucune exploitation connue à ce jour. Cato AI Labs a divulgué les vulnérabilités en tant que recherche sans preuve de campagnes actives. L’évaluation CISA-ADP pour CVE-2026-50548 liste le statut d’exploitation comme “aucun”. Cependant, les vulnérabilités sont notées “automatisables”, ce qui signifie qu’une exploitation fiable à grande échelle est réalisable sans personnalisation par cible — donc la fenêtre entre la divulgation et l’exploitation potentielle est étroite.

(Source : NVD — CVE-2026-50548 Detail)

Q : Désactiver les outils MCP ou de récupération web me protège-t-il ?

Cela réduit mais n’élimine pas la surface d’attaque. Les deux vulnérabilités peuvent toujours être déclenchées via un clone de dépôt empoisonné ou une revue de PR — des vecteurs qui ne nécessitent pas MCP ou la récupération web. La seule atténuation fiable est Cursor 3.0 ou ultérieur.

Q : Pourquoi Cursor a-t-il initialement rejeté les rapports de vulnérabilité ?

Le modèle de menace initial de Cursor (en février 2026) excluait l’utilisation abusive du serveur MCP, même à partir d’intégrations standard comme l’espace de travail officiel Linear.app. Le rejet était une décision de modèle de menace, pas un déni technique — la position de Cursor était que le contenu MCP était en dehors de sa frontière de sécurité. L’escalade du 26 février a conduit l’équipe de sécurité à réévaluer et finalement convenir que le MCP et les autres contenus consommés par l’agent doivent être traités comme faisant partie de la surface d’attaque.

(Source : Cato Networks — DuneSlide: Two Critical RCE Vulnerabilities)

Q : Cursor est-il uniquement vulnérable, ou d’autres IDE IA ont-ils le même problème ?

Cursor n’est pas uniquement vulnérable. Le problème sous-jacent — les agents LLM agissant sur un contenu qu’ils ne peuvent pas distinguer des instructions — est universel pour tous les outils de codage IA autonomes. Cato AI Labs a déclaré divulguer des vulnérabilités similaires dans d’autres agents de codage. Devin Desktop, Claude Code et Aider ont tous eu des incidents d’injection de prompt vers RCE au cours des 12 derniers mois. L’exposition structurelle est la même dans toute la catégorie.

Lectures complémentaires