Cursor IDE's Sandbox Cracked by Prompt Injection — No User Interaction Required
Two logic flaws in Cursor's command execution sandbox let attackers escape the isolation layer and run code on the underlying OS. Patches landed in April. The researchers say Cursor isn't alone.
Key points
- CVE-2026-50548 and CVE-2026-50549 together enable sandbox escape and remote code execution in Cursor IDE.
- Neither flaw requires prior privileges; a normal coding prompt that pulls in attacker-controlled content is enough.
- Cursor version 3.0, released in April, patches both flaws.
- Cato Networks says comparable isolation-layer weaknesses exist in other popular coding agents.
- Agentic tools that parse third-party content are the attack surface; the model itself isn't the only target.
Cato Networks published findings this week on a pair of vulnerabilities in Cursor, the AI-assisted coding environment recently acquired by SpaceX for $60 billion in stock. The flaws, CVE-2026-50548 and CVE-2026-50549, together enable remote code execution by breaking out of the sandbox Cursor uses to contain its internal AI agent. Cato is calling the exploit chain DuneSlide.
Neither CVE requires prior privileges. No specific user action triggers the exploit beyond the victim issuing a normal coding prompt that inadvertently pulls in an attacker-controlled payload, from a poisoned MCP server response or a tainted web search result, for instance.
How does the first flaw work?
The first flaw lives in Cursor's run_terminal_cmd tool. That tool accepts a working_directory parameter that overrides the sandbox's default path restriction, which is supposed to limit file writes to the active project directory. An injected prompt can steer the agent to set that parameter to an arbitrary attacker-controlled path. From there, an attacker can overwrite the cursorsandbox executable itself, plant malicious scripts in shell configuration files, or drop payloads into startup folders like ~/Library/LaunchAgents on macOS.
What does the second flaw add?
The second flaw is a canonicalization failure. Cursor's sandbox resolves symlinks (shortcuts that point to files elsewhere on the filesystem) to verify a file's true location falls inside the project root. When canonicalization fails, because a path doesn't exist or an intermediate directory lacks read permissions, the agent falls back to trusting the original symlink path. An attacker who creates a symlink inside the project directory pointing to a file outside it can exploit that fallback to escape the restriction entirely.
Both vulnerabilities were patched in Cursor version 3.0, released in April. We first reported on DuneSlide on 1 July, and the broader trend of prompt injection reaching into agentic coding tools appeared in our 24 June coverage.
Should you worry if you don't use Cursor?
The bigger concern isn't Cursor specifically. DuneSlide shows prompt injection working as a concrete exploitation path against the software layer implementing an agent, not just the model underneath it. Cato says it's conducting coordinated disclosure across other popular coding agents and has found similar isolation-layer weaknesses elsewhere. Developers running any agentic tool against untrusted content, web results, third-party repositories, MCP responses, should treat sandbox isolation as one layer among several, not a ceiling.
What to watch: whether other vendors patch quietly before Cato's broader disclosures land, and whether any of those CVEs carry severity ratings close to the 9.8 scores these two did.
