DuneSlide: Cursor's Agent Overwrote Its Own Sandbox Binary - CVE-2026-50548 and CVE-2026-50549 (CVSS 9.8)

DuneSlide, disclosed by Cato Networks, is a pair of CVSS 9.8 vulnerabilities in Cursor IDE - CVE-2026-50548 and CVE-2026-50549 - that let zero-click prompt injection escape the IDE sandbox and run code on the operating system. The victim never clicks anything: they issue an innocuous prompt that happens to ingest attacker-controlled content, such as an MCP server response or a poisoned web search result. Both bugs converge on the same endgame - overwriting Cursor's own sandbox helper binary - after which every subsequent terminal command runs with no sandbox at all. Every version before Cursor 3.0 is affected; both are fixed in 3.0, released April 2, 2026. This advisory covers the two mechanisms, why writing to your own guardrail is the pattern to watch, and what to check across a fleet.

What happened

Cursor runs agent terminal commands inside a sandbox, enforced on macOS by a helper binary at /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox. That binary is the boundary. Both CVEs are different routes to writing over it.

CVE-2026-50548 abuses the sandbox's own generosity about working directories. Cursor's run_terminal_cmd tool takes an optional working_directory parameter, and the sandbox permits writes into a command's working folder. When the agent sets that parameter to a non-default path, Cursor adds the path to the allowed-write list without question. Point it at the directory containing cursorsandbox, and the sandbox authorises the write that destroys it. Later commands then run unsandboxed.

CVE-2026-50549 abuses a safety check's failure mode. Before writing, Cursor resolves symlinks to confirm the real destination sits inside the project. The bug is the fallback: when resolution fails - because the target does not exist, or because an attacker has removed read permissions from a directory in the path - Cursor gives up and trusts the unvalidated symlink path. A check that fails open is not a check. The attacker does not need to defeat canonicalization; they need only to make it error.

The trigger is what earns the *zero-click* label. Neither bug requires elevated privileges or deliberate user action. The victim issues an ordinary prompt - summarise this, look that up, use this tool - and the agent ingests attacker-controlled text from an MCP server response or a poisoned search result. From there the injected instructions drive the file write. Cato's demonstrated impact is overwriting cursorsandbox to convert sandboxed terminal commands into fully unsandboxed RCE, compromising both the local machine and connected SaaS workspaces - because the IDE holds tokens for everything it is wired into.

Why this is an agentic-endpoint risk

The sandbox was not bypassed. It was edited. That is the difference between a containment bug and this class: the agent had write access to the artifact that constrained it, so the constraint became just another file. The same logic produced CVE-2026-10591 in AWS Kiro, where hidden text on a web page made the agent rewrite its own mcp.json and auto-reload it. Kiro's target was a config; Cursor's was a binary. Agent self-modification is the shared class, and it converts a transient injection into durable capability.

CVE-2026-50549 also deserves attention as a general lesson in check design. The validation logic was correct; its error path was not. Resolve-then-trust-on-failure is a pattern that appears throughout agent tooling, because agents operate on paths that legitimately may not exist yet, so *cannot resolve* feels like a normal condition rather than a refusal. An attacker only has to induce the error - here by removing read permission on a parent directory. Any allow-list, path check or sandbox rule in an agent harness deserves the question: what does it do when it cannot decide?

Detection is genuinely hard from the outside. The injected content is a legitimate tool response. The write is a signed IDE writing inside its own application directory, which it does during every update. The subsequent unsandboxed commands are the same commands the agent was already permitted to run. EDR sees a trusted application; DLP sees nothing leave at rest. The tractable questions are fleet questions - which endpoints run Cursor before 3.0, which MCP servers can feed them content, and what are their tool calls allowed to do - and MCP servers are one of the eight AI artifact types Anomity inventories per endpoint. The injection mechanism itself is covered in indirect prompt injection explained, and the data-egress shape in the lethal trifecta.

How Anomity surfaces and governs it

First, inventory versions and the content sources feeding the agent. Anomity's unprivileged Endpoint Sensor runs on Windows, macOS and Linux and inventories AI agents, MCP servers, extensions, plugins, skills, secrets, hooks and CLIs. "Which endpoints run Cursor before 3.0" is one query, and so is "which MCP servers are wired into them" - the second matters more here, because an MCP response is the delivery vehicle for a zero-click injection.

Second, decide at the tool call. Neither DuneSlide bug involved a user approving anything, so no consent-based control was ever in the path. Where an agent exposes a hook - for example the PreToolUse event in Claude Code - Anomity evaluates each call against policy and returns allow, deny, or log before it runs. A write targeting an application directory, a sandbox helper, or anything outside the project is exactly the sort of call that should be denied irrespective of which prompt produced it. That is what runtime governance provides when the instruction arrived inside a tool response.

Third, keep the record. Version changes, artifact changes and policy decisions land in a queryable 90-day audit trail, giving a precise exposure window - which machines ran a pre-3.0 build, for how long, and what their agents did. Anomity collects metadata only, with on-endpoint secret redaction, so the SaaS tokens this attack reaches for are never centralized. Findings route to SIEM, Slack, email, or Jira, the platform is SOC 2 Type II, and it complements EDR, DLP, network and GRC tooling. See how it works.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every endpoint running Cursor and record the build. Every version before 3.0 is affected; 3.0 shipped April 2 2026. Verify the running build rather than trusting the updater.
• Verify the integrity of the sandbox helper on macOS - /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox - on any endpoint that ran a pre-3.0 build, since an overwrite persists across restarts.
• Note that patching to 3.0 does not clear DeepJack, a separate deeplink issue reported still reproducible in 3.9.8 with no CVE and no vendor advisory - see the DeepJack advisory.
• Enumerate which MCP servers can return content into Cursor, and treat every tool response as untrusted input rather than trusted data - that is the zero-click delivery path.
• Audit your own agent harnesses for checks that fail open. Wherever a path check, allow-list or sandbox rule can fail to resolve, confirm the failure denies rather than trusts.
• Restrict agent write scope to the project tree and deny writes into application directories outright, regardless of any working-directory parameter the agent supplies.
• For endpoints that ran a pre-3.0 build with active agent use, treat as a potential incident: rotate developer credentials and the SaaS tokens the IDE held, then review connected workspaces for unexpected activity.
• Confirm tool calls are evaluated at a hook with allow/deny/log - see Claude Code permissions and hooks hardening - and run the credential path of your AI agent incident response playbook.

DuneSlide is two CVSS 9.8 routes to the same destination: the agent writing over the thing that was supposed to contain it, triggered by text it read rather than anything the user clicked. Patch to Cursor 3.0 or later, verify the sandbox helper on anything that ran an older build, and then stop treating tool responses as trusted data. For the same class against a config file see the Kiro advisory; for the consent-handoff variants see DeepJack and PromptFiction; for the trust model, the MCP Server Security guide and securing AI coding agents and CLIs. To see which endpoints run a vulnerable build and what runtime governance would deny, request early access.