Two bugs in Cursor, the AI code editor, let a single prompt break out of the safety sandbox and run anything on your machine. No clicking required. No approval box to sidestep.
Just one question, and the damage is done.
Cato AI Labs found the pair and named them DuneSlide. They’re tracked as CVE-2026-50548 and CVE-2026-50549, scoring 9.8 out of 10 (9.3 under CVSS 4.0). Both are already patched in Cursor 3.0, released April 2. Every version before that is vulnerable.
Cursor’s maker says more than half the Fortune 500 use this editor. If you run it, update now. No exceptions.
How it works. Cursor’s AI agent runs terminal commands inside a sandbox by default. DuneSlide is about escaping that box. The entry point is prompt injection — the attacker doesn’t type into your editor directly. They plant instructions inside something your agent reads: a connected service through MCP (Model Context Protocol) or a page returned by a web search.
You ask a normal question. The hidden instructions ride along. Zero-click, because no approval is needed.
Both bugs use the same trick: get the agent to write one file it shouldn’t be allowed to touch, then use that write to flip the sandbox off.
CVE-2026-50548 abuses a setting. The sandbox allows writes into the command’s working folder. That folder is an optional parameter called working_directory. When the agent sets it to a non-default path, Cursor adds that path to the allowed-write list automatically. Injected instructions point it at a system file instead of the project folder. Overwrite the sandbox helper itself — on macOS, that’s /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox — and later commands run completely unboxed. Startup files like ~/.zshrc work as targets, too.
CVE-2026-50549 abuses a safety check. Before writing, Cursor resolves symlinks to confirm the real destination is inside your project. The bug is the fallback: when the check fails (target doesn’t exist, or the attacker removes read access from a folder in the path), Cursor gives up and trusts the symlink’s in-project path instead. An attacker creates a symlink pointing outside the project, forces the check to fail, and Cursor writes straight through to the same sandbox helper.
Once the sandbox is neutralized, the next command runs with full user privileges. That’s the developer’s machine, plus any cloud or SaaS workspaces the editor is logged into.
No signs of real-world exploitation yet. Cato disclosed responsibly starting in February. Cursor initially rejected the reports, saying its threat model didn’t cover MCP server misuse. After Cato escalated, Cursor reopened, triaged, and fixed both bugs in 3.0.
This isn’t the first Cursor sandbreak, and it won’t be the last. Previous bugs — CurXecute, MCPoison, CVE-2026-26268 — all followed the same pattern: poisoned prompt, code execution. The 2.x sandbox was Cursor’s answer. DuneSlide is about answering the answer.
