Two new Cursor IDE vulnerabilities let an attacker break out of the editor’s command sandbox. All it takes is text the AI agent reads on your behalf. Cato AI Labs disclosed the pair, tracked as CVE-2026-50548 and CVE-2026-50549. They’re nicknamed DuneSlide, and both score 9.8 out of 10 on CVSS 3.1 (9.3 on CVSS 4.0). Cursor patched both in version 3.0, released April 2. Every earlier build in the 2.x sandbox line is still exposed.
How the Cursor IDE vulnerabilities actually work
Cursor’s agent runs shell commands for you. So the editor wraps those commands in a sandbox to limit what they can touch. The idea is simple. Even if the AI does something odd, the harm stays inside the project folder. DuneSlide shows that wall had two holes.
CVE-2026-50548 hits the run_terminal_cmd tool’s working_directory parameter. When the agent sets that parameter to a folder outside the default path, Cursor adds the new folder to its allowed-write list. It doesn’t check first. An attacker who can steer the agent’s instructions can point that parameter at the sandbox helper binary itself. Or at shell startup files like ~/.zshrc. Either way, it gets overwritten.
CVE-2026-50549 is a symlink problem. Cursor is meant to resolve a shortcut to its real target and confirm that target sits inside the project, before allowing a write. But when that resolution fails, say because the target path doesn’t exist yet, Cursor falls back to trusting the symlink’s apparent location instead. A planted symlink can then redirect a write straight to the sandbox helper. No path traversal required.
No click needed
Both bugs run without any explicit approval from the user. The attacker’s instructions arrive hidden inside content the agent reads while doing ordinary work. That could be a response from a connected MCP server, or a page pulled back from a web search. A developer only has to issue an innocent prompt that causes the agent to ingest that content. Once the sandbox helper is overwritten, the next command Cursor runs executes unsandboxed. It runs as the developer, on the developer’s machine, and on any cloud or SaaS workspace the editor is signed into.
What the CVSS score actually means
The Cursor IDE vulnerabilities carry the highest severity NVD scores. NVD lists both bugs at CVSS 3.1 base score 9.8. The vector string is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Read plainly, that says the attack works over the network and takes low effort. It needs no privileges and no user interaction. It threatens full loss of confidentiality, integrity and availability once it lands. That “UI:N” piece, no user interaction, matters most here. A developer doesn’t approve anything, click anything, or see a warning before the sandbox comes down.
How Cursor responded
Cato AI Labs reported the flaws to Cursor on 19 February. Cursor initially rejected the report on 23 February, arguing its threat model did not cover MCP server misuse. Cato escalated to Cursor’s security team on 26 February, and the reports were reopened for triage. Cursor confirmed the working-directory fix shipped with the 3.0 client on 1 April. It confirmed the symlink fix in the same release on 1 June. Both CVE IDs were assigned on 5 June. There’s no public evidence of exploitation before the patch.
CSO Online’s write-up on the disclosure said researchers view DuneSlide as evidence of a wider pattern, not a Cursor-only mistake. It reported that other AI-assisted coding tools are getting similar scrutiny for the same class of flaw. That fits what these two Cursor IDE vulnerabilities actually show. An agent that reads untrusted content and also runs commands needs a boundary. That boundary can’t rely on the agent to hold itself to it.
What to do about it
Fixing these Cursor IDE vulnerabilities starts with one step. Update to Cursor 3.0 or later before doing anything else. That alone closes both holes. Teams running agent-based coding tools more broadly should treat any content an agent can read as untrusted input. MCP responses, fetched web pages, third-party repositories, all of it. That’s exactly what carried the injected instructions here. Review which MCP servers your developers have connected. Each one is a potential delivery path for hostile text the agent will act on without asking first.
It’s also worth checking how your organisation tracks AI tooling at all. Many teams adopted Cursor, or a similar agent, informally, one developer at a time. It never went through the same asset inventory or patch tracking as everything else on the network. That makes a fix like this one easy to miss, because nobody owns the update. Put AI coding agents on the same patch cadence as any other software that can run commands and reach the internet. That is exactly what they are.
The wider lesson holds even outside Cursor. Sandboxing an AI agent’s commands is good practice. But a sandbox that trusts parameters the agent itself sets, without checking a source the agent didn’t touch, isn’t much of a sandbox. Anyone building or auditing similar tools should test how they handle parameters and symlinks. Check whether the tool trusts itself too much.