Cursor's default-on sandbox was the right call. When the 2.x line put the agent's terminal commands inside a locked box — refusing writes outside the project unless the user opts in — that was the security posture every AI code editor should ship. Two flaws in that wall, named DuneSlide by researchers at Cato AI Labs, prove it isn't permanent. Patches shipped in Cursor 3.0 on April 2, two and a half months before the public write-up on July 1, which is exactly how coordinated disclosure is supposed to look. The lesson isn't whether to trust the agent. It's what to do today, and what to add underneath.
The blast radius matters: more than half the Fortune 500 use Cursor, per its maker. A zero-click sandbox escape in that install base isn't a hobbyist problem — it's a patch-everything-on-every-laptop problem.
What Cursor's sandbox was for, in one paragraph
In the 2.x line, Cursor runs the AI agent's terminal commands inside a sandbox by default — a locked box that limits what those commands can touch. The point is simple: an agent that gets confused, misdirected by prompt injection, or just has a bad day cannot, by itself, rewrite your ~/.zshrc or replace a system binary. The sandbox is the difference between "the agent did something dumb" and "the agent did something catastrophic." Most tools Cursor drives over the Model Context Protocol (MCP) inherit that sandbox by default, so the box is the assumption your workflow was built on.
DuneSlide is about walking out of that box.
DuneSlide: how the two flaws open the box
[[DIAGRAM: attacker plants instructions → agent reads them via MCP tool result or web fetch → run_terminal_cmd is called with a crafted working_directory or a symlinked target → write lands outside the project → sandbox helper or shell startup file overwritten → next command runs with no sandbox]]
Two CVEs, both rated 9.8/10 on the CVSS 3.1 scale and 9.3 under CVSS 4.0. Both were patched in Cursor 3.0, released April 2. Every version before 3.0 is affected.
The attacker never types into your Cursor. They plant instructions in something your agent reads on your behalf — an MCP tool result, a web page returned by the built-in search, a README fetched through any connected service. You ask a normal question. The hidden instructions travel alongside the answer, and the agent follows them. There is no click to refuse, no approval box to ignore. Zero-click.
Both bugs use the same trick: get the agent to write one file it should not be allowed to write, then use that write to switch the sandbox off.
CVE-2026-50548 abuses a parameter. Cursor's run_terminal_cmd accepts an optional working_directory. The sandbox already permits writes inside that folder. When the agent — or injected instructions pointing at it — sets working_directory to a non-default path, Cursor adds that path to the allowed-write list without asking. Aim it at a system file instead of the project — on macOS, /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox — overwrite the sandbox helper itself, and every later command runs with no sandbox at all. Startup files like ~/.zshrc work as targets too: once rewritten, the next shell launch executes whatever the attacker left there.
CVE-2026-50549 abuses a safety check. Before writing, Cursor resolves symlinks to confirm the destination is what the user asked for. The published source at thehackernews.com cuts off mid-explanation on the exact bypass; the class is the same as 50548 — a check the model can be tricked into passing, a write that lands somewhere it shouldn't. Read the full disclosure before treating either CVE as fully understood.
What zero-click means for a dev machine
A sandbox escape isn't theoretical damage. Once the sandbox is off:
- Arbitrary commands run with the developer's full user privileges. No prompts, no review, no undo.
- Anything on the box is fair game: SSH keys in
~/.ssh,~/.aws/credentials, browser cookies, the source for the project you're paid to write, secrets in.envfiles you happened to be editing. - A second-stage payload — a crypto miner, an info-stealer, a reverse shell — lands before the developer notices anything is wrong. The bug isn't "the user got phished." The bug is "the user's tools followed instructions the user never saw."
Cursor's maker says more than half the Fortune 500 use the tool. Half the Fortune 500 has at least one developer with private keys, customer data, and a build pipeline on the same machine Cursor is installed on.
How to actually close this window today
The patch is one download away. Every step below assumes you want Cursor installed at all; if you don't, uninstall it and stop here.
1. Update to Cursor 3.0 or later. Open Cursor → Cursor → About Cursor and read the version number. Anything before 3.0 is exposed to both CVEs. Use the in-app Check for Updates prompt — it serves the patched build — or reinstall from Cursor's official download page if a clean install is faster.
2. Lock the agent's write surface in the meantime. Even on 3.0, treat the sandbox as defence in depth, not the whole wall. Scope every MCP server you actually need:
// ~/.cursor/mcp.json
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "${env:GITHUB_TOKEN}" }
}
}
}
Disable MCP servers you aren't actively using. Untrusted MCP servers are how an attacker plants instructions your agent will read.
3. Don't run Cursor with sudo, ever. The sandbox assumes the user has limited privileges. If the agent has root, the sandbox is decoration.
4. Make startup files append-only. A symlinked or chmod'd ~/.zshrc derails persistence even if a future CVE bypasses the sandbox again.
# ext4 (most Linux filesystems)
chattr +a ~/.zshrc
# edit: chattr -a, edit, chattr +a
On macOS (APFS), chattr +a doesn't apply — a less-privileged shell wrapper or a SIP-protected location is the practical equivalent. The point is the same: make the file your shell trusts the hardest file on the box to overwrite.
5. Treat every agent that touches the network as a browser. Web results, fetched READMEs, MCP tool payloads — every one is attacker-controlled content the model will read. Cursor 3.0 patches the specific bypasses; the class of vulnerability is older than DuneSlide and isn't going away.
6. Verify what your agent saw. Before letting the agent run anything novel, ask it to quote the source of any non-trivial instruction. If it can't, refuse the action.
What doesn't change when the model does
Today's vulnerability is CVE-2026-50548 and CVE-2026-50549. Tomorrow's will be CVE-2027-XXXX. The pattern is permanent: a model that reads untrusted text and acts on it through a write-capable tool will be tricked into writing somewhere it shouldn't. Cursor shipped a sandbox; the sandbox had two holes. The next editor will ship a different safety net; that safety net will have different holes. The fix-from-the-vendor cycle — patch, restart, repeat — is the model-tax you keep paying.
The part underneath doesn't churn. A clean checkout workflow where the agent proposes changes and a tool outside the agent's control decides what lands. A build server that pulls from a branch the agent can't write to directly. A secrets store the agent cannot resolve to plaintext, even when it tries. Run these, and which AI editor you wired into them becomes a switching cost measured in hours, not a security migration measured in weekends.
This is the layer that doesn't churn: the interface where the AI proposes and the project decides — shaped once, reused across every editor upgrade, every new model, every next DuneSlide.
The sandbox earned its keep this week. So did the patch. So will the next one — and the one after that. Patch fast. Build the layer that doesn't have to be re-patched every six weeks.
Top comments (1)
This post highlights an important security class of vulnerability in AI-powered IDEs like Cursor: sandbox escape flaws that can escalate from prompt injection or tooling misuse into local system compromise.
The key takeaway is that “agentic” coding environments must be treated as execution platforms first, and productivity tools second. Even when fixes are shipped quickly, the broader risk model remains complex: untrusted model outputs interacting with file systems and shells.
This reinforces the need for defense-in-depth: strict sandboxing, containerization, least privilege, explicit user approvals, and robust audit logs. It also raises questions about enterprise readiness of AI coding assistants. Without strong isolation, even small prompt injection paths can become full system risks.
Overall, this is a valuable reminder that security must evolve alongside AI tooling. Looking forward to deeper hardening patterns and transparent security models for agent-based IDEs going forward. Clear isolation standards will define next generation AI development tools secure.