DuneSlide: prompt injection escapes the Cursor IDE sandbox to OS-level RCE
Cato AI Labs (July 1, 2026) showed a single poisoned prompt — served through an MCP server or a web result — can overwrite Cursor's sandbox helper and reach zero-click OS-level RCE. Fixed in Cursor 3.0.
What is this?
On July 1, 2026, Cato AI Labs (Itay Ravia) published DuneSlide: Two Critical RCE Vulnerabilities via Zero-Click Prompt Injection in Cursor IDE. It describes two independent flaws in the Cursor AI code editor — a tool Cursor says is used by over half the Fortune 500 — that let an ordinary-looking prompt break out of the editor’s command sandbox and run arbitrary code on the developer’s machine. Both were rated 9.8/10 and confirmed patched in Cursor 3.0 (released April 2, 2026); every earlier version is affected. The research is presented defensively, with no evidence of exploitation in the wild.
The trigger is indirect prompt injection: the attacker never types into your editor. They plant instructions in something your agent reads on your behalf — a connected service reached over the Model Context Protocol (MCP) or a page returned by a web search — and a normal question drags the hidden instructions along. No click, no approval dialog, hence “zero-click.” What makes DuneSlide notable is the target: prompt injection reaches past the model layer and revives classic file-write bugs in code paths nobody used to treat as attacker-reachable.
How it works
Cursor’s 2.x line runs the agent’s terminal commands inside a sandbox by default, without asking the user to approve each one — a deliberate trade against approval fatigue. Both flaws follow the same shape: get the agent to write one file it should not be allowed to write, then use that write to switch the sandbox off. The high-value target on macOS is the sandbox helper binary itself (the cursorsandbox executable under the Cursor app bundle); overwrite it and every later command runs unconfined.
The first flaw abuses a tool parameter. When a sandboxed command runs, Cursor builds a policy allowing writes into the command’s working folder — and working_directory is an optional parameter on the run_terminal_cmd tool. When the model sets it to a non-default path, that path is added to the writable allowlist without validation, so injected instructions can point it at a system file instead of the project. Startup files such as ~/.zshrc or ~/Library/LaunchAgents are equally viable targets.
The second flaw is a symlink canonicalization failure, independent of the first. Before writing, Cursor resolves symlinks to confirm the true destination sits inside the project root. The bug is the fallback: when canonicalization fails — because the target doesn’t exist, or the attacker strips read permission from a directory in the path — Cursor trusts the original in-project symlink path instead of rejecting the write. A write-only symlink pointing outside the project therefore passes the check, and the write lands on the sandbox helper anyway. Same escape, different door. No working payload is reproduced here; the mechanism is described at the level the disclosure already made public.
Example prompt
A defensive, non-actionable sketch of the DuneSlide sandbox escape. Payloads are redacted — it shows why the trust boundary fails, not how to reproduce it.
# 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.
Why it matters
This is the lethal trifecta realized inside a developer tool: the agent holds real authority (local file writes, command execution, signed-in cloud sessions), it ingests untrusted content, and the two connect with no human in the loop. Once the sandbox helper is overwritten, the next command runs as you — full control of the workstation plus any SaaS or cloud workspace the editor is authenticated to. And the entry point is mundane: a poisoned result from a standard, innocuous MCP integration is enough, which is exactly the case Cursor initially argued fell outside its threat model.
DuneSlide is not a one-off. It sits in a documented run of Cursor issues that begin with a poisoned prompt and end in code execution, each defeating a different guardrail — the same prompt-injection-to-RCE pattern seen across agent frameworks, and closely related to symlink-based approval escapes in coding agents. Cato states it is disclosing similar flaws in other coding agents and argues the problem is structural, not a string of unrelated bugs.
Defenses
- Update now. Both issues are fixed in Cursor 3.0. Upgrading is the single highest-value action; every pre-3.0 build is affected.
- Don’t let tool parameters redraw the security boundary. The root cause of the first flaw is that a model-controlled argument (
working_directory) silently widened the write allowlist. Sandbox scope must be derived from trusted policy, never from parameters the LLM can set — treat all tool arguments as untrusted input. - Canonicalize paths safely and fail closed. Resolve symlinks before any write and deny when resolution fails, rather than falling back to the unresolved in-project path. Enforce the project-root boundary on the final target, and forbid writes to executables, app bundles, and shell startup files regardless of how the path was derived.
- Constrain the injection source. Auto-executing agent commands on content pulled from MCP servers or web search is the trigger. Gate irreversible or out-of-project actions behind approval, and apply the Agents Rule of Two so content ingested from an untrusted source cannot directly drive privileged file writes.
- Assume the editor is a reachable endpoint. Run coding agents with least privilege, scope their credentials, and monitor for writes to sandbox binaries and startup files — the fingerprint of an escape attempt.
Status
| Item | Reference | Date | Notes |
|---|---|---|---|
| DuneSlide disclosure | Cato AI Labs (Itay Ravia) | 2026-07-01 | Two independent RCE flaws; CVSS 9.8; research, no in-the-wild use |
| Working-directory write | CVE-2026-50548 | 2026-06-05 (ID assigned) | run_terminal_cmd param added to sandbox write allowlist |
| Symlink canonicalization | CVE-2026-50549 | 2026-06-05 (ID assigned) | Fail-open fallback trusts in-project symlink path |
| Reported to Cursor | Cato timeline | 2026-02-19 | Initially rejected as out-of-threat-model, then re-triaged |
| Fix shipped | Cursor 3.0 | 2026-04-02 | All versions before 3.0 affected |
The durable lesson is the authors’ own: giving an LLM autonomous command execution turns every path where an agent parameter or a resolved filename crosses a trust boundary into attack surface. Sandboxing is necessary but insufficient — the boundary has to be enforced on trusted policy and the final resolved target, not on values the model can be talked into supplying.
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