system: OPERATIONAL
← back to all hacks
AGENTS CRITICAL NEW

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.

2026-07-22 // 6 min affects: cursor-ide, coding-agents, mcp, llm-agents

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

  1. Update now. Both issues are fixed in Cursor 3.0. Upgrading is the single highest-value action; every pre-3.0 build is affected.
  2. 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.
  3. 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.
  4. 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.
  5. 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

ItemReferenceDateNotes
DuneSlide disclosureCato AI Labs (Itay Ravia)2026-07-01Two independent RCE flaws; CVSS 9.8; research, no in-the-wild use
Working-directory writeCVE-2026-505482026-06-05 (ID assigned)run_terminal_cmd param added to sandbox write allowlist
Symlink canonicalizationCVE-2026-505492026-06-05 (ID assigned)Fail-open fallback trusts in-project symlink path
Reported to CursorCato timeline2026-02-19Initially rejected as out-of-threat-model, then re-triaged
Fix shippedCursor 3.02026-04-02All 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