SURIQ
An AI coding agent that can open a terminal needs a wall between the text it reads and the commands it runs. In Cursor, that wall was a sandbox. Two flaws that Cato AI Labs disclosed this month, together named DuneSlide, let the agent write past that wall and overwrite the sandbox's own enforcement binary, turning a poisoned document into code running on the developer's machine. Both carry a CVSS score of 9.8. Cursor fixed them in version 3.0. No exploitation in the wild has been reported, but the write-up is public now, so the details are in the open.
A sandbox that could edit its own guard
The first flaw, CVE-2026-50548, lives in the run_terminal_cmd tool. When the agent set the working_directory parameter to a non-default path, Cursor added that path to the sandbox's allow-write list without checking it. Injected instructions could point that write at a system file and overwrite cursorsandbox, the helper binary inside the Cursor application bundle that enforces the sandbox in the first place. Once that binary is neutralized, the commands that follow run with the developer's own privileges.
The second, CVE-2026-50549, is an independent path to the same place. Cursor resolves symlinks to confirm a write target sits inside the project. Cato found that when the resolution fails, because the target does not exist or the attacker strips read access from a folder in the path, Cursor falls back to trusting the link's in-project path and writes anyway. A write-only symlink pointing outside the project lets an attacker reach the same sandbox binary.
The common thread is the defect, not the two code paths. A sandbox that shares a writable filesystem with the binary that enforces it is not a boundary. Any write primitive that reaches that binary is a full bypass, and producing writes is exactly what a coding agent does all day.
| Detail | CVE-2026-50548 | CVE-2026-50549 |
|---|---|---|
| Mechanism | working_directory added to the sandbox allow-write list unchecked | symlink resolution falls back to trusting the in-project path |
| Write target | the cursorsandbox helper binary | the same cursorsandbox helper binary |
| Severity | CVSS 9.8 | CVSS 9.8 |
| Fixed in | Cursor 3.0 | Cursor 3.0 |
The attack surface is everything the agent reads
The person driving Cursor never types the exploit. The instructions arrive inside content the agent ingests on the user's behalf: a connected service reached through the Model Context Protocol (MCP, the standard that lets an agent pull in outside tools and data), or a web page pulled in by a search the agent itself ran. No click, no extra privilege, no interaction beyond an ordinary prompt. We have written this shape before, with Amazon Q running a repo's config file as the user and a clean repository talking a coding agent into a reverse shell. For an agent with tool access, every data source it touches is executable input.
That is the part worth arguing with. Cursor initially rejected the report, citing the MCP server threat model, before reopening and shipping the fix. The framing is the problem. If the agent auto-runs terminal commands built from what an MCP server returns, the MCP server is not outside the threat model. It is the threat model. Treating untrusted read content as beyond scope is how a guardrail becomes optional in practice.
Two directions on the same target
DuneSlide is the code-execution angle. Days before it went public, researchers documented the Djinn stealer looting the config files of AI coding assistants, MCP settings included. One campaign wants to run code through the developer's AI toolchain; the other wants to steal from it. Attackers are converging on the same surface from both sides, and it sits on endpoints that rarely carry the monitoring a production server would. The developer laptop running an agent with terminal access and cloud keys in reach is becoming the soft entry that the hardened server no longer is.
Confirm you are past 3.0, then watch the writes
Check the Cursor version across every machine that runs it. Anything before 3.0 is affected; 3.0, released in April, and later builds carry both fixes. Auto-updating installs are likely already safe, so the real exposure is pinned versions, offline machines, and shared build images that froze on a 2.x release.
The injection itself is invisible, but the write is not. File integrity monitoring on the Cursor application bundle, and on the sandbox helper specifically, catches the one step the attack cannot skip: overwriting that binary. Pair it with endpoint detection that flags the Cursor helper process spawning a shell it has no reason to spawn. Then scope which MCP servers your agents are allowed to connect to, and treat agent web-search results as untrusted input, because that is the lane the payload rides in.
Expect more of this class as agent tooling keeps shipping a sandbox as its primary control. A sandbox is doing a permission boundary's job, and it will keep losing that job until the enforcement lives somewhere the agent it contains cannot write to.