SPR{K}3back to research

The Prompt That Turns Off the Sandbox

July 2, 2026 · SPR{K}3 Research

Two bugs in Cursor, one of the most widely used AI code editors, let a single ordinary-looking prompt reach outside the editor's safety sandbox and run any command on a developer's machine. No click. No approval box. The attacker doesn't type anything into your session at all — they just plant instructions somewhere your AI agent will read on your behalf.

That's the whole attack. Read a normal-looking file, get owned.

The bug in one sentence

Cato AI Labs found the pair, named the chain DuneSlide, and reported it as CVE-2026-50548 and CVE-2026-50549 — both scored 9.8 out of 10. Cursor patched both in version 3.0, released April 2, 2026; every earlier version is affected. The CVE IDs were assigned June 5. Cursor's maker says more than half the Fortune 500 use the product, so the patch window matters (The Hacker News coverage; Cato's writeup).

How the escape actually works

Starting in its 2.x line, Cursor runs the terminal commands its AI agent issues inside a sandbox — a locked-down environment meant to stop a stray instruction from touching the rest of the machine. DuneSlide is about getting out of that box, and the way in is prompt injection: hidden instructions arrive inside something the agent reads on the user's behalf, such as a connected service over the Model Context Protocol (MCP) or a page pulled back from a web search. The user asks a completely normal question. The hidden instructions ride along with the answer. Because nothing needs a click or an approval, the attack is zero-click.

Both variants use the same underlying trick: get the agent to write to one file it shouldn't be allowed to touch, then use that single write to switch the sandbox off entirely. One abuses an optional working-directory setting that Cursor trusts without question; the other abuses a symlink-resolution check that fails open instead of closed when it can't verify a target. Either way, the write lands on the sandbox's own helper process, and every command after that runs unrestricted — as the user, with access to whatever cloud or SaaS sessions the editor is signed into.

There's no evidence DuneSlide has been used in the wild. Cato is presenting it as research, and the public vulnerability record shows no known exploitation as of publication. Cato also says the initial report was rejected — Cursor's team said abuse of MCP servers fell outside their threat model — until escalation got the issues reopened, triaged, and fixed.

This is the fourth time, not the first

DuneSlide isn't an isolated slip. It's the fourth publicly disclosed chain since August 2025 where a poisoned prompt in Cursor ends in arbitrary code execution, each one defeating a different guardrail:

Cato says it's disclosing similar flaws in other coding agents too, and frames the pattern as structural rather than a string of unrelated one-offs.

Why "zero-click" is the real headline

Every one of these bugs starts the same way: the agent reads something — a file, a config, a web page, a tool result — and treats it as an instruction instead of as data. That's not a Cursor-specific coding mistake so much as a category of risk that shows up anywhere an AI agent is trusted to act on content it didn't ask a human to vet first. As agentic coding tools get wired into more of the developer toolchain — MCP servers, CI systems, package registries — the number of places a hidden instruction can hide only grows.

The takeaway

An AI coding agent that reads the open web, a teammate's Slack message, or a third-party MCP server has to treat all of it as potentially hostile — not because any particular source is likely to be malicious, but because the cost of being wrong once is full code execution on a developer's machine. Sandboxes help, but as DuneSlide shows, a sandbox is only as strong as the one file-write path nobody thought to lock down. The open question for the whole category, as Cato puts it, is whether "treat every input as hostile" becomes the default design assumption, or stays a patch-by-patch scramble after each new escape is found.

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.