Two critical Cursor flaws let a zero-click prompt injection escape the sandbox and run code

Cato AI Labs published research on July 1 describing two independent ways to make Cursor's AI agent run arbitrary code on the machine it is installed on, with no click from the user. The firm calls the pair DuneSlide. Both carry a 9.8 CVSS score (9.3 under the newer CVSS 4.0 scale), and both were assigned CVE IDs on June 5: CVE-2026-50548 and CVE-2026-50549. Cursor patched both in version 3.0, which shipped April 2. Every release before 3.0 is affected. Cursor's maker says more than half the Fortune 500 use the editor.

There is no evidence either bug has been used in a real attack. Cato is presenting this as research, and the public vulnerability record shows no known exploitation. That is the honest framing, and it is worth keeping in mind before the number "9.8" does its usual work.

What the sandbox does

Start with what Cursor was trying to protect. In the 2.x line, the editor runs the shell commands its agent decides to execute inside a sandbox, by default, without stopping to ask the user for approval each time. The point was to kill approval fatigue. If every command needs a click, people click through, and a prompt injection that reaches the terminal becomes a straight path to code execution. The sandbox was Cursor's answer to an earlier run of exactly that kind of bug.

DuneSlide is about getting out of the box. The entry point for both flaws is prompt injection, and the attacker never touches your Cursor. They leave instructions inside something the agent reads for you, like a response from a connected MCP server or a page pulled in by a web search. You ask an ordinary question, the hidden instructions ride along, and because there is no click or approval involved, Cato labels it zero-click.

Both flaws then run the same play: get the agent to write one file it should not be able to write, and use that write to switch the sandbox off. On macOS the target is the sandbox helper binary itself, at /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox. Overwrite it, and every command after that runs unsandboxed.

The two doors

CVE-2026-50548 abuses a parameter. When the sandbox runs a command, it allows writes into that command's working directory. The working directory is an optional field, working_directory, on Cursor's run_terminal_cmd tool, and it is set by the model. When the agent picks a non-default value, Cursor adds that path to the allowed-write list without checking it. A prompt injection points it at a system file instead of the project folder. Startup files like ~/.zshrc work as targets too. The notable part is the category. A working directory is not something a remote attacker can normally control. Here the agent is the thing setting it, and the agent takes instructions from text.

CVE-2026-50549 abuses a safety check, and it is fully independent of the first. Before writing, Cursor resolves symlinks to confirm the real destination sits inside your project. The bug is the fallback. When that resolution fails, because the target does not exist or a directory in the path has had its read permission stripped, Cursor gives up and trusts the symlink's in-project path instead of refusing. So the attacker makes a symlink that points outside the project, forces the check to fail, and Cursor writes straight through it to the same sandbox helper. Different door, same room.

Once the helper is overwritten, the next command runs as you. That is the developer's machine, plus any cloud or SaaS workspace the editor is signed into, from one prompt that looked harmless.

The disclosure was not smooth

The timeline is worth reading, because it is not the usual clean handshake. Cato reported both issues on February 19. Four days later, Cursor rejected them, on the grounds that its threat model did not cover misuse of MCP servers, including standard ones like the official Linear workspace. Cato escalated on February 26. Cursor reopened the reports, triaged them, confirmed the working-directory fix for 3.0 on April 1, and confirmed the symlink fix on June 1. Cursor has since published its own advisory for the symlink bug, and the NVD record is live.

The rejection is the tell. "Our threat model does not account for MCP server misuse" is a defensible sentence right up until the agent will read anything an MCP server hands it and act on the contents. If the product treats external text as instructions, then external text is part of the attack surface, whether or not the threat model says so.

Not the first

DuneSlide follows a run of Cursor bugs with the same shape: poisoned input, then code execution, each one stepping around a different guardrail. CurXecute (CVE-2025-54135) and MCPoison (CVE-2025-54136) both landed in August 2025. A booby-trapped Git hook (CVE-2026-26268) followed in February. The 2.x sandbox was the fix for that wave. DuneSlide is a way around the fix.

Cato says it is disclosing similar flaws in other coding agents and argues the problem is structural, not a string of one-offs. That is the part worth watching. Every agent that reads the open web and can run commands has the same core exposure. It cannot reliably tell your instructions from instructions buried in the data it fetches. Sandboxing narrows the blast radius. It does not answer the question. The fix that matters here is the boring one: update to 3.0.