A sandbox is supposed to hold even when the thing inside it is compromised. Cursor's agent terminal sandbox didn't — and the trigger wasn't code the agent was told to run, it was content the agent merely read.
What the source says
Cato AI Labs disclosed the flaw to Cursor as part of a pair of vulnerabilities they named DuneSlide. This one, CVE-2026-50548, is a vendor-published GitHub Security Advisory, rated critical — CVSS 9.8 (3.1) / 9.3 (4.0).
Cursor's default sandbox for agent-run terminal commands is meant to confine writes to the project workspace. The advisory says the sandbox instead granted write access to the working directory of whatever command the agent ran — and working_directory was a parameter the agent itself controlled, not something fixed by the sandbox.
Because Cursor's agent can act on instructions embedded in content it merely reads — an MCP tool's response, a web page fetched mid-task — an attacker who could get such content in front of the agent didn't need it to run malicious code at all. They needed it to set working_directory to a sensitive path and overwrite cursorsandbox, the helper binary that enforces sandboxing in the first place. Once that binary was overwritten, every command that followed ran unsandboxed.
No approval prompt intervened. No click was required. Reading poisoned content was the entire attack.
What it doesn't establish
This is a vendor-published advisory with a CVE and a fixed version — about as verifiable as a security finding gets — but it's still one disclosed pair of vulnerabilities (the other, CVE-2026-50549, separately exploited a symlink-resolution fallback for the same effect), not a claim about Cursor's sandbox architecture generally or about other agents' sandboxes. There's no evidence in the advisory that this was exploited outside Cato AI Labs' own research.
Why it's worth tracking anyway
Most "agent did something destructive" incidents involve the agent executing an instruction a user gave it, however badly. This one required no instruction from the user at all — the entire attack surface was "content the agent reads during a normal task." That reframes the sandbox threat model: it's not enough for a sandbox to hold against commands the agent is told to run, it has to hold against parameters the agent sets for itself, including under prompt injection it never disclosed to the user.
If you're evaluating any agentic coding tool's sandbox, the question this incident raises is specific: does the sandbox's write scope depend on any value the agent — not the human, not a fixed config — controls? Cursor's did, and the fix in 3.0 was removing that dependency, not adding a warning.
Top comments (0)