Critical Cursor AI IDE Flaws Expose OS to Remote Code Execution

Cursor has become the default AI editor for a fast-growing slice of working developers. It automated the boilerplate, kept the keyboard on the home row, and turned "write me a migration" into a 2-second prompt. That ubiquity is exactly why a sandbox bug in Cursor now matters to a lot of people at once.

On July 3, 2026, Cato Networks disclosed two flaws in Cursor — CVE-2026-50548 and CVE-2026-50549, both at CVSS 9.8 — collectively named DuneSlide. Both reach the same destination: remote code execution on the host operating system, outside the IDE's sandbox. Both can be triggered without the user clicking anything beyond an initial prompt. Neither waits for the user to approve a terminal command.

This is a real vulnerability in a real tool. It is also fixable, patchable, and a useful case study in how AI editor sandboxes need to be built. Here is the shape of the bug, what it lets an attacker do, and how to keep shipping with Cursor today.

What the DuneSlide vulnerabilities actually are

Cursor runs terminal commands inside a sandbox binary called cursorsandbox. Anything the agent wants to execute — npm install, pytest, cat, whatever — is supposed to be confined to the project directory. DuneSlide is two independent bugs that both end at the same target: rewriting cursorsandbox itself. Once that binary is overwritten, every subsequent command the agent runs escapes the sandbox.

CVE-2026-50548 is a sandbox-boundary bug. The sandbox allow-list is keyed on the working_directory parameter. Cursor expects that parameter to default to the project root; if a non-default value is supplied, that path is added to the allow list. An attacker who can influence the prompt — through a malicious MCP server response, a poisoned README, or a copy-pasted snippet — can instruct the agent to set working_directory to an attacker-supplied path outside the project. The sandbox then permits writes inside that external path. The attacker overwrites cursorsandbox from there.

CVE-2026-50549 is a path-canonicalization bug, completely independent from the first. Cursor tries to be careful about writes outside the project: before allowing a write, it resolves the target path to its canonical form and checks that it lives inside the project. The flaw is in the fallback. If the agent's path canonicalization encounters a symlink it cannot resolve, Cursor falls back to using the original symlink path — the symlink itself, not its target. The attacker creates a write-only symlink inside the project pointing to cursorsandbox. Cursor's check sees the symlink path (inside the project), permits the write, and the symlink dutifully forwards it to the binary outside the sandbox.

Same outcome, two paths in. Either one is enough to overwrite cursorsandbox. After that, every subsequent terminal command the agent runs is unsandboxed.

How the exploit chain actually runs

The trigger is the same for both CVEs: the user asks Cursor to ingest something attacker-controlled. Common shapes include a malicious MCP server response, a hostile README.md, or a snippet of code that doubles as instructions. Cursor's agent reads it, treats it as task context, and — because the agent automatically executes terminal commands inside the sandbox without prompting the user for approval — starts running things.

For CVE-2026-50548, the chain looks like this:

// Shape of an attacker-controlled tool call — for defender understanding only
{
  "tool": "run_terminal",
  "args": {
    "working_directory": "/tmp/attacker-supplied",   // escapes project scope
    "command": "cat pwned-binary > /path/to/cursorsandbox"
  }
}

Cursor's sandbox checks: is /tmp/attacker-supplied allowed? Yes — it was just added to the allow list via the manipulated parameter. The write proceeds. cursorsandbox is now the attacker's binary.

For CVE-2026-50549, the chain looks like this inside a project directory:

# 1. attacker-controlled prompt instructs the agent to create a symlink
ln -s /path/to/cursorsandbox ./project/link

# 2. agent then writes to ./project/link, intending to write inside the project
# Cursor's path canonicalization can't resolve it and falls back to the symlink path
# 3. the write is silently redirected to cursorsandbox

The malicious payload does not need to be clever — it just needs to make Cursor do one of these two things. Neither write needs a privilege escalation. Both happen inside the IDE's normal sandbox path.

Why the sandbox didn't catch it

Cursor's design assumption was that working_directory defaults to the project root and that path canonicalization always succeeds. Both assumptions break under adversarial input. The deeper issue is that the IDE auto-runs terminal commands in the sandbox without prompting the user — which is exactly what makes Cursor fast, and exactly what makes DuneSlide silent. There is no "Allow this command?" modal for the user to catch the overwrite.

A 9.8 CVSS reflects that: network-attackable in the sense of "ingest a file", no user interaction beyond that, low complexity, high impact. The CVEs are not exotic. They are the kind of bug every sandboxing system eventually has to fix.

How to use Cursor safely today

Cursor is not unsafe to keep using — it is unsafe to use without these checks in place. The DuneSlide patches will land, and once they do, the immediate risk drops. In the meantime:

Update Cursor the moment a fix is published. The Cursor team's release notes are the canonical signal; check the release channel before any session that touches third-party code.

Treat MCP servers as untrusted by default. DuneSlide is triggered by ingesting attacker-controlled payload. Every MCP server you connect is a prompt-injection surface. Audit them. Remove the ones you do not need. Pin versions where you can.

Disable auto-execution of terminal commands if your Cursor build exposes that toggle. Some builds ship an "ask before running" mode. Turn it on. The two-second speedup is not worth a 9.8.

Run Cursor as a normal user, never elevated. A non-sandboxed RCE inside Cursor still gets the privileges of the account that launched it. A developer account is dramatically less catastrophic than an admin one.

Sandbox the project, not just the IDE. A container, a VM, or a disposable dev environment for any repo you did not write yourself. If cursorsandbox is bypassed, the blast radius should be one disposable container, not your laptop.

Audit symlinks and unusual paths in project directories before opening untrusted repos. The CVE-2026-50549 chain needs an attacker-created symlink in the project tree. A quick find . -type l -ls will surface anything suspicious.

The pattern: assume the sandbox is a best-effort boundary and put a real one underneath it.

The part that doesn't change when the editor does

Cursor will patch DuneSlide. The next editor will ship a different CVE. AI coding tools move fast, and the surface area — MCP servers, prompt injection, agent terminal access — is large enough that there will be more findings like this. The reasonable response is not to stop using AI editors; it is to put the durable layer in the right place.

The durable layer is the project itself. A deterministic folder structure, one component API that renders the same on web, iOS, and Android, and conventions any agent — Cursor today, Claude Code tomorrow, something else next year — can read and respect without ambiguity. That is what does not churn. Cross-platform templates that survive the IDE are the part of your stack that the next 9.8 will not touch.

This is the bit OTF is built around. One codebase, web plus mobile, structured conventions an agent can grep rather than guess. Cursor can use it, Claude Code can use it, the next editor will use it. The vulnerability surface moves with the tool; the templates stay.

What to take from this

Cursor is fast and useful. DuneSlide is real and serious, and the fix will land. Update when it does, tighten the trust boundary around your editor, and do not grant your AI agent more privilege than your shell already has. The interesting work in 2026 is not choosing the right editor — it is building project structures stable enough that the editor does not matter.