DuneSlide and the Sandbox Illusion: What a 9.8-Severity Cursor Escape Teaches About Agent Security

Two critical vulnerabilities in Cursor IDE, scored 9.8 on CVSS 3.1, let a crafted prompt escape the editor's command sandbox with no user click and no approval dialog. The security implications extend well beyond a single tool. Tracked as CVE-2026-50548 and CVE-2026-50549 and collectively dubbed "DuneSlide," these flaws were discovered by Cato AI Labs and patched in Cursor 3.0 on April 2, 2026. There is no evidence of real-world exploitation. But the architecture they expose, and the disclosure process around them, tells you something important about the state of agent containment right now.

Key Takeaways

• DuneSlide (CVE-2026-50548 and CVE-2026-50549) allowed OS-level remote code execution through Cursor's terminal sandbox via indirect prompt injection, with zero user interaction required.
• The first bug let an attacker-controlled payload set an arbitrary working_directory that the sandbox blindly added to its own write-allow list, eventually overwriting the sandbox enforcement binary itself. The second exploited a symlink resolution fallback that trusted the apparent path when the real-path check failed.
• Cursor's initial response was to reject the report, stating their threat model did not account for MCP server misuse. They reversed course after escalation and shipped fixes in version 3.0.
• DuneSlide is not an outlier. Concurrent disclosures (GhostApproval, Friendly Fire, Claude Code's symlink CVE, Amazon Q credential-theft chains) show zero-click sandbox escapes are becoming the norm across agentic coding tools, not a surprising edge case.
• The structural lesson: sandboxes that trust agent-supplied parameters are cosmetic. Enforcement boundaries must sit outside the agent's own reasoning loop.

What exactly are CVE-2026-50548 and CVE-2026-50549?

They are two distinct remote code execution vulnerabilities in Cursor IDE's terminal sandbox, both exploitable through indirect prompt injection. Neither requires a click, a confirmation dialog, or any user approval. A victim only needs to prompt the IDE to ingest attacker-controlled content: a malicious document, a poisoned MCP server response, a crafted codebase file. The agent does the rest.

Cursor's sandbox allows its AI agent to execute terminal commands automatically inside a project directory. The design intent is containment: the agent can run build commands, install dependencies, execute tests, all scoped to the project. The two DuneSlide bugs break that scope from different angles.

How does the working-directory bug work (CVE-2026-50548)?

Cursor's run_terminal_cmd tool accepts an optional working_directory parameter. When the LLM sets this parameter to a non-default value, the sandbox blindly adds that path to its allowed-write list. The parameter is not validated against the project boundary. An attacker who can influence the LLM's tool call (via indirect prompt injection embedded in any ingested content) can point working_directory at an arbitrary filesystem location, including the directory containing the sandbox's own enforcement binary. Once that directory is writable, the agent can overwrite the binary. The sandbox is now whatever the attacker wants it to be.

Read that again. The containment mechanism trusts the contained agent to specify where containment applies. The agent decides its own jail boundaries.

How does the symlink bug work (CVE-2026-50549)?

Before writing to a path, Cursor's sandbox attempts to resolve symbolic links and confirm the real destination is inside the project directory. That is the correct check. The problem is what happens when the check fails. Rather than refusing the write, the editor falls back to trusting the apparent (unresolved) path. So an attacker creates a symlink inside the project that points outside it. The resolver fails to confirm the destination. The fallback logic says "the path looks fine." The write proceeds to the real, out-of-scope destination.

This is a classic fail-open pattern, the kind you learn about in the first week of any systems security course. Fail-open in a containment boundary is not a bug. It is the absence of containment.

Why does zero-click matter here?

Because the entire value proposition of agent sandboxing rests on the assumption that the user is the trust anchor. The user approves commands. The user reviews diffs. The user clicks "allow." DuneSlide sidesteps all of that. The flaws abuse Cursor's automatic terminal command execution inside the sandbox, which by design does not prompt the user. The attacker's payload rides in on content the user already asked the agent to process. No dialog appears. No confirmation is requested. The agent's own tool parameters are the attack surface, and those parameters are shaped by whatever the agent just read.

This is the core problem with what you might call approval theater. The approval prompt exists for the commands the sandbox already flags as dangerous. The commands that execute automatically inside the sandbox, by definition, do not trigger it. DuneSlide exploits the automatic-execution path and then widens the sandbox from within. The user never sees anything unusual because the system considers everything that happened to be normal operation.

What happened during the disclosure process?

The timeline is instructive. Cato AI Labs reported both vulnerabilities to the Cursor team on February 19, 2026. Cursor rejected the report on February 23. Their stated justification: Cursor's threat model does not account for MCP server misuse, even for standard, innocuous integrations like the official Linear.app workspace connector.

Let that sink in. The vendor's position was that a widely deployed integration surface is outside their threat model. MCP (Model Context Protocol) servers are how agentic IDEs connect to external tools and data sources. They are a primary ingestion path for untrusted content. Excluding them from the threat model is like a web browser vendor declaring HTTP responses out of scope.

Cato escalated on February 26. Cursor reversed course. The working-directory fix shipped with Cursor 3.0 on April 2. The symlink fix was confirmed shipped in the same release by June 1. CVE IDs were assigned June 5.

The four-day rejection window matters less than the reasoning behind it. If a vendor's threat model explicitly excludes the primary vector through which untrusted content reaches the agent, the sandbox is not a security boundary. It is a convenience boundary that happens to look like a security boundary.

Is DuneSlide an isolated case?

No. It sits in a pattern that is now unmistakable. Within the same narrow disclosure window, separate researchers disclosed GhostApproval and Friendly Fire, which defeat both the approval prompt and model judgment securing Claude Code, Cursor, Amazon Q, and Codex. Claude Code had its own symlink-based sandbox escape (CVE-2026-39861) in versions before 2.1.64, where sandboxed processes created symlinks pointing outside the workspace and unsandboxed processes later wrote through them without prompting the user.

AWS patched Amazon Q Developer's language server on May 27 in version 1.69.0, addressing CVE-2026-12958. That same advisory disclosed CVE-2026-12957, in which a poisoned repository could auto-load a configuration file and run commands capable of stealing a developer's AWS credentials. Google patched a related flaw in Antigravity on May 22.

Cursor itself had prior art. CurXecute (CVE-2025-54135, August 2025), discovered by the same team when it was still operating as Aim Security, showed that a planted Slack message could rewrite Cursor's config file and run commands even after the user explicitly rejected the edit. That was fixed in version 1.3. Then came MCPoison. Then a Git-hook flaw in February 2026. Then DuneSlide.

Separately, Straiker's "NomShub" research demonstrated that combining indirect prompt injection with Cursor's tunnel feature could give an attacker persistent, authenticated shell access to a victim's machine, triggered simply by opening a malicious repository.

These are not unrelated bugs. They are the same class of flaw, found by different teams, in different products, in the same quarter. The vulnerability is architectural.

What does a mature threat model for agentic tools actually look like?

It starts by treating every content ingestion path as an untrusted input boundary. MCP server responses, web search results, repository files, clipboard contents, documentation fetched at inference time: all of these are first-class attack surface. Not edge cases. Not "misuse." The expected operating surface of the tool.

Concretely, a threat model for an AI coding agent should include at minimum:

• Indirect prompt injection via any ingested content (files, API responses, MCP payloads, pasted text)
• Parameter manipulation of tool calls by the agent itself, influenced by injected instructions
• Symlink and path-traversal attacks against any filesystem boundary the sandbox claims to enforce
• Configuration file poisoning via repository contents (.cursor.vscode, MCP config files)
• Persistence mechanisms that survive session boundaries (tunnels, cron jobs, shell profiles)

If your threat model does not include these, your sandbox is a suggestion. The agent will follow a different suggestion if the prompt tells it to.

Why do agent sandboxes keep failing the same way?

Because they are built on a flawed trust assumption: that the LLM inside the sandbox is a cooperative actor whose outputs can be trusted to stay within policy. Sandboxes in agentic tools typically enforce boundaries by inspecting the agent's declared intent (the tool call, the file path, the command string) rather than by constraining what is physically possible regardless of intent.

This is the difference between a policy boundary and a capability boundary. A policy boundary says "the agent should not write outside the project directory." A capability boundary says "writes outside the project directory will fail at the kernel level regardless of what the agent requests." DuneSlide exploited a policy boundary. The agent said "my working directory is /path/to/sandbox/binary" and the policy engine said "okay, that's your working directory now, writes there are allowed."

A capability boundary would not have this problem because the set of writable paths would not be modifiable by the agent's own parameters. It would be set once, externally, at session initialization, and enforced by a mechanism the agent cannot influence. Think filesystem namespaces, seccomp profiles, read-only bind mounts. The tools exist. They have existed for decades. Container runtimes use them. Agentic coding tools, mostly, do not.

Cato frames this as systemic. They state explicitly that Cursor is far from the only AI-powered IDE with such logic flaws in its isolation layers, and that they are in the process of responsibly disclosing vulnerabilities in all popular coding agents.

What does this mean for developers using agentic coding tools today?

First, patch. If you are running Cursor, you need version 3.0 or later. If you are running Claude Code, you need 2.1.64 or later. If you are running Amazon Q Developer, you need 1.69.0 or later. These are not theoretical risks, even though no exploitation has been observed in the wild. The attack requires only that you open a repository or ingest a document containing a crafted payload. The payload can be subtle. You will not notice it.

Second, reduce trust surface. If your agentic IDE connects to MCP servers, every one of those servers is an ingestion path for indirect prompt injection. Audit which MCP integrations you actually use. Remove the ones you don't. For the ones you keep, understand that their responses are untrusted input to a system that can execute commands on your machine.

Third, assume the sandbox is incomplete. Run your agentic IDE inside a VM, a container, or at minimum a separate user account with no access to credentials, cloud provider configs, SSH keys, or browser sessions. This is defense in depth. It is also the only layer that would have stopped DuneSlide cold, because a properly isolated environment has nothing valuable to write to even if the sandbox boundary is breached.

Fourth, watch the disclosure stream. Cato AI Labs has stated they are disclosing similar flaws across the category. More CVEs are coming. This is not a one-quarter problem.

How does this connect to broader agent containment?

Coding agents are the canary. They are the first widely deployed category of AI agents with direct access to operating system primitives (filesystem, terminal, network). The containment failures showing up now are previews of what will happen as agents gain access to email, calendars, financial systems, infrastructure management, customer data.

The pattern is consistent: the agent is given a capability (execute commands, write files, make API calls), a sandbox is placed around that capability, the sandbox trusts the agent's own parameters to determine scope, and an indirect prompt injection manipulates those parameters to exceed scope. The sandbox never had a chance because it was asking the potentially compromised agent to self-report its intentions accurately.

This is why we think about containment differently at Selina. Our architecture does not give a single inference path unchecked access to system primitives. We use a stack of frontier models, routed per task, and the routing itself is a containment boundary: no single model sees the full context needed to reconstruct a harmful action end-to-end. Memory is encrypted at rest, though we are clear that memory is NOT end-to-end encrypted, because a slice of each request reaches a frontier provider at inference. Files and transfers via SelinaSEND are end-to-end encrypted. Non-content operational metadata is kept for a short retention window. We state these limits because the limits are the design. Claiming more than is true is how you end up with a sandbox that trusts the agent to define its own boundaries.

We do not claim this makes us invulnerable to prompt injection. It does not. What it means is that the blast radius of a successful injection is bounded automatically, not by asking the model to behave, but by ensuring the model does not have the access needed to misbehave at scale. There is a difference between "the agent chose not to do the harmful thing" and "the agent could not do the harmful thing." We aim for the latter wherever possible and are honest about where we fall short.

What should vendors learn from the DuneSlide disclosure timeline?

Three things.

One: your threat model is your security posture. If MCP responses are out of scope, you have declared that the primary content ingestion path of your product is not a security boundary. Attackers do not care about your threat model. They care about your attack surface. Those are the same thing whether you acknowledge it or not.

Two: rejection of a valid security report because it falls outside your stated threat model is a governance failure, not a technical one. Cursor rejected the DuneSlide report on February 23 and reversed after escalation on February 26. The fix shipped April 2. The four-day rejection did not change the vulnerability. It changed the timeline and the trust relationship with the research community.

Three: if you ship an agent with OS-level access to machines used by over half of the Fortune 500, your sandbox is critical infrastructure. Test it like critical infrastructure. Red-team it against indirect prompt injection specifically, not just direct prompt injection. Publish the results. The era of "trust us, the sandbox works" is over. DuneSlide ended it.

The sandbox was always an illusion

Not entirely. Sandboxes do raise the cost of exploitation. They do prevent accidental damage from benign misuse. They are worth having. But they are not, and have never been, a sufficient containment mechanism for an autonomous agent that processes untrusted input and has access to system primitives.

DuneSlide is a clean demonstration of why. The sandbox trusted the agent. The agent was manipulated. The sandbox fell. No user was asked. No dialog appeared. The whole thing happened inside the boundary that was supposed to prevent it from happening.

If you are building or deploying agentic tools, the question is not whether your sandbox will be bypassed. It is what happens after it is bypassed. If the answer is "full OS-level code execution," your containment architecture needs rethinking. Not a thicker sandbox wall. A fundamentally different relationship between the agent and the capabilities it can invoke.

The fixes in Cursor 3.0 are necessary and good. They close two specific holes. But the architectural question, should an agent's own tool parameters define the enforcement boundary of its sandbox, remains open across the entire category. Until it is answered differently, DuneSlide will not be the last escape. It will be the one we point to when explaining why the next one was predictable.

If you want an assistant built with these constraints in mind from the start: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io