Safeguard
AI Security•

Cursor DuneSlide: two 9.8 flaws let prompt injection escape the sandbox

Cato AI Labs disclosed DuneSlide on 1 July 2026. Two Cursor bugs let injected text break out of the terminal sandbox. Cursor 3.0 fixes both.

Safeguard Security Team
6 min read

On 1 July 2026, Cato AI Labs published DuneSlide, a pair of flaws in the Cursor code editor: CVE-2026-50548 and CVE-2026-50549. Both let a prompt injection hidden in content the agent reads break out of Cursor's terminal sandbox and run commands with the developer's own privileges. NVD scores each 9.8 under CVSS 3.1 and 9.3 under CVSS 4.0.

Cursor fixed both in version 3.0, released on 2 April 2026. The public write-up came almost three months later, after the CVE IDs were assigned. Cato reported no evidence of exploitation in the wild.

What's affected

Every Cursor release before 3.0. Since the 2.x line, Cursor runs agent terminal commands inside a sandbox by default, and both bugs are ways to turn that sandbox off.

  • CVE-2026-50548: the agent can set the working_directory parameter of its terminal tool to a path outside the project. Before 3.0, the sandbox granted write access to whatever directory the command ran in, so the allowed-write list grew to include a sensitive location.
  • CVE-2026-50549: before writing a file, the agent resolves the target path to confirm it sits inside the workspace. When that resolution fails, Cursor fell back to the original in-workspace path and wrote without approval. An attacker-created symlink that points outside the project, combined with a target that does not exist or a folder with read permission removed, gets a write through.

The Hacker News describes the payoff in both cases: overwrite the cursorsandbox helper (on macOS, under /Applications/Cursor.app/Contents/Resources/app/resources/helpers/), and every later command runs unsandboxed. Startup files such as ~/.zshrc are the other named target.

The entry point is the part worth noticing. The injected instructions can arrive through an MCP connector response or a web search result, so the victim never clicks anything. In the words of The Hacker News coverage: "There is no click to fall for and no approval box to ignore."

How to check if you're exposed

Check the installed version on each machine. On macOS:

defaults read /Applications/Cursor.app/Contents/Info CFBundleShortVersionString

Anything below 3.0 is affected. On Linux or Windows, use Help, About inside Cursor, or cursor --version.

If you ran an older build against untrusted repositories or with MCP servers that return third-party content, look for signs of tampering:

ls -l /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox
shasum -a 256 /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox
ls -lt ~/.zshrc ~/.zshenv ~/.zprofile ~/.bashrc 2>/dev/null

Compare the helper's hash with one from a clean install of the same version, and check whether any shell startup file changed at a time you cannot explain. Also list symlinks inside repositories the agent has touched:

find ~/code -type l -lname '/*' -not -path '*/node_modules/*' 2>/dev/null | head -50

An absolute symlink inside a project is not proof of anything, but it is where to start looking.

What to do now

  1. Update every Cursor install to 3.0 or later. Do not assume auto-update ran on laptops that stay offline or on locked-down images.
  2. Inventory the MCP servers your developers have connected to Cursor. Remove those nobody uses.
  3. Rotate cloud and SaaS tokens on any machine where the sandbox helper hash or a shell startup file looks wrong.
  4. Add a version floor for AI editors to your endpoint checks, the same way you track browsers.
  5. Tell developers that web search results and MCP responses are untrusted input to the agent, not just to them.

How this could have been avoided

  • Resolve paths strictly and fail closed. CVE-2026-50549 existed because a failed path check ended in "write anyway". A check that cannot decide should refuse.
  • Never let the agent widen its own write allowlist. CVE-2026-50548 let a model-chosen parameter extend what the sandbox could write. Sandbox policy should come from the user or the product, not from tool arguments.
  • Make the sandbox helper read-only to the sandboxed process. The whole chain ends in overwriting one executable. Protecting that file with OS permissions or code signing checks removes the payoff.
  • Treat connector output as untrusted. Cursor first rejected the report because its threat model excluded MCP misuse, according to Cato. A standard connector that relays user-written text is an injection channel.
  • Isolate the agent from your home directory. A dev container or VM means a sandbox escape lands in a disposable environment with no shell profile worth poisoning.

Why it matters

Sandboxes are only as strong as the code that decides what is inside them. Both DuneSlide bugs are boundary logic errors, not memory corruption: a path that was trusted when it should have been refused, and a directory that was allowed because the model asked for it. Cato says similar sandbox escapes exist in other coding agents and calls the weakness structural.

Defenders should also notice that the two bugs are independent. Fixing the working directory handling alone would have left the symlink route open, which is why a sandbox needs defense in depth rather than one check.

There is also a timing lesson. The fix shipped on 2 April and the CVEs were published in late June. Anyone who watched only CVE feeds learned about a patched issue weeks after the patch existed. Version floors for developer tools protect you during that gap.

Try it yourself

Pick one repository where you use an AI coding agent. Write down every source of text the agent reads without you: MCP responses, search results, issue comments, README files. Then decide which of those you would allow to influence a terminal command. The demo below shows how an MCP guardrail sits between an agent and its tools.

Click through it at your own pace, or open it full screen.

Quick check

Which Cursor version fixes both DuneSlide CVEs?

Cursor 3.0, released on 2 April 2026. Every earlier version is affected.

Why does a path-resolution failure matter for sandbox security?

In CVE-2026-50549, when Cursor could not resolve a symlink target it trusted the in-workspace path and wrote without approval. A failed check should refuse the write, not allow it.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.