Your Cursor Sandbox Was Never the Thing Protecting You: Inside DuneSlide's Zero-Click RCE

No link to click. No approval box to dismiss. No suspicious file to open. A developer asks Cursor an entirely innocuous question, the agent reads a web search result or an MCP server response on their behalf, and somewhere inside that response is a payload that ends with arbitrary code running on their machine — outside any sandbox, at full user privilege.

That's DuneSlide: two vulnerabilities in Cursor's AI code editor, CVE-2026-50548 and CVE-2026-50549, each scored 9.8 out of 10 on CVSS. Cato AI Labs, which discovered and disclosed them, calls the exploit chain zero-click because it requires no user interaction beyond the prompt that was going to happen anyway. Cursor patched both in version 3.0 on April 2, 2026, and every version before it was affected — on an editor Cursor says over half the Fortune 500 now uses.

The bug isn't the sandbox. It's what the sandbox was hiding​

Here's the thing that actually matters once you've read the technical details below: fixing DuneSlide fixed a sandbox-escape bug. It did not fix the reason DuneSlide was catastrophic instead of merely embarrassing. Cursor's coding agent runs commands with the full standing permissions of the developer's own machine — every file, every credential, every SSH key already sitting on disk — and the sandbox was the only thing standing between "agent reads a web page" and "attacker has your laptop." When the sandbox had a bug, there was no second layer behind it. That's the design decision this post is actually about, and the CVEs are the proof, not the point.

How a write bug becomes a full compromise​

DuneSlide is two independent bugs that both defeat the same protection: Cursor's sandbox restricts which paths a command can write to, scoped to the project directory. Break that restriction and you can write anywhere the developer's user account can write — including the files that enforce the sandbox itself.

CVE-2026-50548 abuses an optional parameter. When Cursor's agent runs a shell command, it can set a working_directory — normally the project folder. The sandbox trusts this parameter without re-validating it against the project root. A prompt-injected instruction can set working_directory to a path outside the project and point a write at /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox on macOS — the actual helper binary that enforces the sandbox boundary. Overwrite that file, and the next command the agent runs invokes the corrupted helper instead of the real one. There is no sandbox left to escape, because the thing that would have enforced it is now attacker-controlled code running with the developer's own privileges. That's the write-bug-to-RCE link closed: not "a file got overwritten," but "the file whose entire job was enforcing isolation got overwritten, and everything after that runs unsandboxed."

CVE-2026-50549 abuses a fallback path. Cursor checks whether a symlink's real target sits inside the project before allowing a write through it — a reasonable control. The bug is what happens when that check can't complete: if the target doesn't exist yet, or the attacker has stripped read access from a directory in the resolution path, canonicalization fails. Cursor's fallback, in that failure case, is to trust the symlink's claimed in-project path instead of refusing the operation. An injected instruction creates a symlink inside the project that points outside it, engineers the canonicalization failure, and gets the same out-of-bounds write CVE-2026-50548 reaches by a different route.

Either bug alone gets an attacker from "text the agent reads" to "arbitrary write outside the sandbox." From there, overwriting cursorsandbox is what turns an arbitrary write into full, persistent, unsandboxed code execution on the host.

The part that makes it zero-click​

Both bugs need the agent to read attacker-controlled text and act on embedded instructions — that's prompt injection, not a phishing link. The payload doesn't need the developer to visit anything malicious. It arrives however the agent already pulls in outside content on the developer's behalf: a response from a connected MCP server, or a page returned by a web search the agent ran to answer a normal question. The developer's only "action" is asking Cursor something ordinary. Cato AI Labs' write-up is explicit that the exploit requires no prior privileges and no specific user interaction beyond that — which is the whole reason this scored 9.8 instead of a more contained 6 or 7. A bug that requires a click is a bug you can train around. A bug that fires on a routine prompt is not.

The disclosure timeline nobody with an agent-in-the-loop can ignore​

The dates matter as much as the CVSS score, because they show how long a known-critical bug can sit unfixed even with a responsible researcher pushing on it:

More than five weeks between initial report and Cursor even agreeing it was a real vulnerability. Over four months between report and both fixes shipping. That gap existed because the vendor's own threat model didn't initially treat "content an MCP server returns" as untrusted input worth defending against — the exact same class of input every deploy agent, chat-triggered pipeline, and MCP-connected tool on this blog's beat ingests by design.

What would have bounded this even if the escape had still worked​

Patching the sandbox stops these two specific bugs. It does nothing about the next one, because the underlying exposure — an agent holding the developer's full, standing, indefinite machine permissions — is a design choice, not a bug. This blog has made the same argument about deploy agents elsewhere: giving an agent a permission level instead of a scoped, expiring capability means one bug in the isolation layer is one bug away from total compromise, every time, forever.

Here's the concrete version of what a bounded design looks like for exactly this chain:

• A write-jail scoped to the project directory, enforced independently of the working-directory parameter. CVE-2026-50548 exists because the sandbox trusted an agent-supplied path without re-checking it against the project root at write time. A write-jail that re-validates every write target — regardless of what working_directory claims — would have blocked the write to cursorsandbox specifically, because that path is never inside any project directory, no matter what parameter the agent passes.
• A credential scoped to one task, with a TTL measured in minutes, not the length of an IDE session. Even if a future bug defeats the write-jail too, the blast radius changes entirely depending on what the agent is holding when it happens. Standing developer-machine access, valid indefinitely, means a successful escape reaches every file, key, and credential on disk for as long as the developer is logged in — which for most people is all day, every day. A capability scoped to "the one command this task needs, expiring when the task completes or in N minutes, whichever is first" means a successful escape reaches only what that single task could already touch, for a window measured in minutes. Same exploit chain, same 9.8 severity bug — a fundamentally smaller blast radius, because the thing the attacker inherits was never the whole machine to begin with.

Neither of those changes requires waiting for Cursor's next sandbox rewrite. They're architectural choices available to anyone building an agent that runs commands on a user's behalf — including a platform whose own agents deploy and roll back production infrastructure.

The lesson generalizes past one editor​

DuneSlide is specific to Cursor's implementation, but the shape of the failure isn't. Any tool where an agent reads untrusted content — an MCP response, a web page, a webhook payload — and then acts on it with standing permissions has the same exposure, whether the isolation layer is a sandbox helper binary, a container boundary, or a cloud IAM role. The fix that actually holds up isn't "audit the isolation layer harder." It's not giving the agent standing authority to defeat in the first place.

Bex.co's own deploy agents don't hold a standing permission level — each action is a scoped, expiring capability for the one deploy or rollback it's executing, not a key to the whole fleet. If you're building or running agents that touch production, check out Bex.co on GitHub.

Sources​

• Cato Networks: DuneSlide — Two Critical RCE Vulnerabilities via Zero-Click Prompt Injection in Cursor IDE
• The Hacker News: Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox and Run Commands
• SecurityWeek: Critical Cursor AI Code Editor Flaws Could Lead to OS-Level Remote Code Execution
• CSO Online: Sandbox bypass flaws in Cursor IDE highlight prompt injection as an RCE vector
• Hard2bit: Prompt injection as an RCE vector in AI editors.