DuneSlide: two sandbox flaws let a prompt injection reach full code execution from Cursor's coding agent

What happened

Cato Networks' AI Labs found two vulnerabilities in Cursor, the AI-powered coding editor built by Anysphere, and named the pair DuneSlide. Cursor's Agent can run terminal commands on a developer's behalf, and when it does, a sandbox is meant to confine any file it writes to the project directory. Both flaws defeated that sandbox.

The first, CVE-2026-50548, exploited the terminal tool's own working-directory setting. The tool accepts a working_directory parameter, and the sandbox added whatever path it was given to its list of writable locations without checking that the path actually stayed inside the project. An attacker did not need to compromise anything to supply that path. Per Cato's reported findings, a prompt injection carried in content the agent was already reading, a connected MCP server or the result of a web search, could steer the agent to set working_directory to a location outside the project and overwrite a file there, including the sandbox's own helper binary or a shell start-up file such as ~/.zshrc.

The second, CVE-2026-50549, exploited a fallback in the sandbox's own safety check. Before allowing a write through a symbolic link, Cursor tries to resolve the link to confirm the real destination is inside the project. When that resolution failed, rather than refusing the write, the sandbox fell back to trusting the original, unresolved link path. An attacker-controlled symlink pointing outside the project was written to as though it were safe.

Both CVEs carry a CVSS score of 9.8, and both required nothing from the user beyond the agent doing what it ordinarily does: reading content it was pointed at. Cato's own description of the trigger is that it fires "when a victim makes an innocuous prompt that inadvertently ingests a threat actor-controlled payload from an untrusted source, such as an MCP server or a web search result."

Cato reported the findings to Cursor, and reporting on the disclosure describes an initial setback: Cursor's first response reportedly declined the reports on the basis that its threat model did not treat misuse of MCP servers, even a standard one such as the official Linear workspace integration, as in scope. Cato escalated, and Cursor reopened the reports days later. Cursor fixed both flaws in version 3.0, released 2 April 2026. The CVE identifiers were assigned in early June 2026, and the research became widely known through tier-1 security press around the start of July. No evidence has surfaced that either flaw was used against a real target. This is a researcher-found and vendor-patched pair of vulnerabilities, not a confirmed breach.

This is not the first sandbox-boundary flaw found in Cursor this year. CVE-2026-22708, reported by Dan Lisichkin of Pillar Security Research and fixed in Cursor 2.3 (published 14 January 2026), showed that certain shell built-ins could bypass the terminal tool's command allowlist entirely, letting a prompt injection poison the shell environment so that a later, individually safe command ran a malicious payload instead. Different mechanism, same category of failure: a boundary that validated some of the ways an attacker-influenced value could reach a privileged operation, and missed others.

The duty engaged

Everything below is a duty analysis on researcher-disclosed, vendor-patched facts, as at 5 September 2026. There is no adjudicated finding, no regulator action, and, on the evidence available, no victim. The value of the entry is in what the flaws show about where the design duty falls, not in a harm that occurred.

A coding agent's sandbox has to validate every path by which an attacker-influenced value can reach a write. A tool that runs terminal commands with elevated trust on a developer's machine, and is explicitly built to ingest untrusted external content, a web search result, an MCP server response, as part of ordinary operation, takes on a duty to treat that content as adversarial the moment it can influence a file-system operation. Both CVEs are the same root failure expressed twice: the sandbox checked some inputs and not others. A working_directory parameter went unchecked in one. A canonicalisation failure defaulted to trust rather than refusal in the other.

The reported initial rejection is the sharper point, and it needs the right amount of caution attached to it. If accurately reported, Cursor's first response treated a standard, vendor-endorsed integration, the official Linear MCP server, as outside its own threat model for prompt injection. That is precisely the assumption indirect prompt injection is built to defeat: trusting a source's identity does not make its content safe once an agent parses that content into instructions. This detail comes from a single tier-1 outlet's account of Cato's disclosure; Cato's own post could not be reached to verify it directly, and it is recorded here with that caveat rather than as an established fact.

Fail-open design is the second, narrower lesson. CVE-2026-50549's fallback, treat the unresolved path as safe when resolution fails, is a fail-open choice in a security boundary. A sandbox whose default behaviour on an error condition is to permit rather than refuse converts an edge case into an exploit.

Data protection exposure is downstream and conditional, not direct. No unauthorised access to any real system is confirmed here, so no breach-notification duty is engaged on the facts as they stand. But any organisation running Cursor with Auto-Run enabled on a project that touches personal data was, for the life of these two flaws, one prompt injection away from an attacker with code execution on that machine. Article 32's security-of-processing obligation falls on that organisation as controller or processor for its own choice to run an unpatched, internet-facing tool in that mode. It does not touch the vendor directly, and it did not require any confirmed exploitation to be a live risk while the flaws were unpatched.

The liability chain

The allocation here runs to the vendor, on the same reasoning the register applied to EchoLeak: the deployer is a bystander to a flaw in the product's own security boundary.

Anysphere carries the gravity, as the designer of the sandbox that failed. The specific choices that let each flaw through, trusting a user-suppliable working-directory value without a boundary check, and falling back to trust rather than refusal when symlink resolution fails, were Anysphere's engineering decisions. The risk that a coding agent would be pointed at attacker-controlled content through the integrations it is built to support is not a remote or unforeseeable one. It is the entire premise of prompt injection as a named risk category, and it was foreseeable to the party that built the sandbox and chose which inputs to validate.

A developer using Cursor as intended did nothing wrong. Connecting a standard MCP server, having the agent read a web page, and running the agent in Auto-Run mode are all ordinary, vendor-supported uses. Nothing about typical use required a security-aware developer to do anything differently to be exposed. That is why the gravity does not travel downstream to the user.

If Cato's account of the initial rejection is accurate, it bears on how promptly and in good faith the vendor treated a good-faith report, not on where the underlying liability falls. The flaw existed from the point the sandbox shipped with these gaps. A slow or reluctant response to a correct report would extend the window of exposure, but it does not shift responsibility for the design choice itself.

What would have prevented it

• Validate every attacker-influenceable path against the sandbox boundary, not just some of them. Treat any value that can affect where a write goes, whether it arrives as a tool parameter, an environment variable, or a resolved symlink target, as untrusted input requiring a strict check against the project root before the write proceeds.
• Fail closed on a canonicalisation failure. When a sandbox cannot confirm that a path resolves inside the project, the correct default is to refuse the operation, not to fall back to the original, unverified path.
• Do not let a source's reputation substitute for content validation. An official, vendor-endorsed MCP integration is still a channel for attacker-controlled content once an agent parses what it returns into instructions. A threat model that exempts "standard" integrations from adversarial-input treatment is the assumption indirect prompt injection is designed to break.
• Prefer OS-level sandboxing over in-application path-string checks. A real filesystem or container boundary that constrains where a process can write, independent of what parameter values the agent supplies, is more resilient than validation logic living inside the same application the attacker is trying to manipulate.
• Treat a report describing attacker-controlled content flowing through a trusted integration as in scope from the first read. Whatever the outcome of the specific report here, a vulnerability-disclosure process should not need escalation to recognise that a "standard" data source is still an untrusted one from the model's point of view.

Mapped controls

• OWASP Top 10 for Agentic Applications 2026: the primary fit is ASI02 Tool Misuse and Exploitation, since the underlying defect in both CVEs is the terminal tool's own validation of attacker-influenceable parameters, not a goal the agent chose for itself. Secondary: ASI05 Unexpected Code Execution (RCE), the consequence both flaws share once the sandbox boundary is crossed. Prompt injection is the delivery mechanism for both. The vulnerability itself lives in the tool's parameter handling.
• NIST AI RMF: a MAP failure in the first instance, if the reported initial rejection is accurate, since a threat model that does not treat MCP-server and web-search content as adversarial input has not mapped a foreseeable risk. MEASURE and MANAGE follow once mapped correctly: Cato's testing found the gap, and the version 3.0 patch is the management response.
• A narrower regulatory note. Cursor is an application built on top of underlying language models rather than itself a general-purpose AI model with systemic risk, so the EU AI Act's Article 55 provider duties, the frame this register has applied to OpenAI's and Anthropic's own model evaluations, fit less naturally onto Anysphere as the application layer. The more apt regulatory lens for a security flaw in a widely distributed piece of software is product and cybersecurity law rather than AI-specific regulation. This register will watch for a live case that tests exactly where that line falls.
• The general rule the incident stands for: a coding agent's sandbox is only as strong as its least-validated path to a privileged operation. When a product is explicitly built to ingest untrusted external content as part of ordinary use, every parameter an attacker can influence through that content needs the same boundary check, and a failure in any one of them is enough. It stands alongside Amazon Q as the register's second coding-agent entry, and it is the sandbox-boundary counterpart to the vendor-locus reasoning this register applied to OpenAI's evaluation-agent breach of Hugging Face: the gravity belongs to the party that built and shipped the boundary, not the party who used the product as intended.

Sources

• The Hacker News, "Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox and Run Commands" - the fullest available account, including the disclosure timeline (reported to Cursor mid-to-late February 2026, an initial rejection, escalation, and the reopened report), the CVE IDs and CVSS scores, and Cato's own description of the trigger condition, quoted directly - checked 5 September 2026 [tier-1 secondary; see provenance note below]
• SecurityWeek, "Critical Cursor AI IDE Flaws Could Lead to OS-Level Remote Code Execution" - corroborates the CVE IDs, CVSS 9.8 scores, Cato Networks as researcher, and the 2 April 2026 patch in Cursor 3.0 - checked 5 September 2026 [corroborating]
• CSO Online, "Sandbox bypass flaws in Cursor IDE highlight prompt injection as an RCE vector" - corroborates the CVE IDs and the no-click, no-interaction trigger via MCP servers or web search results - checked 5 September 2026 [corroborating]
• GitHub Security Advisory GHSA-82wg-qcm4-fp2w - the official advisory for the earlier, related CVE-2026-22708 (Terminal Tool Allowlist Bypass via Environment Variables), affected versions up to 2.2, patched in 2.3, published 14 January 2026, credited to Dan Lisichkin of Pillar Security Research [primary]
• Cato Networks / Cato AI Labs, "DuneSlide: Two Critical RCE Vulnerabilities" (catonetworks.com/blog/duneslide-two-critical-rce-vulnerabilities/) - the origin of the research and the named source for the initial-rejection detail. The post could not be fetched directly (blocked by the site's own bot-protection service); its content here is drawn from the tier-1 outlets above that quote and describe it directly. The rejection detail, specifically, appears only in The Hacker News's account and is flagged as such in the body above - checked 5 September 2026 [primary, inaccessible; provenance noted]

Cite this entry as AIR-2026-011 (https://companyscope.io/register/air-2026-011). Entry IDs are stable; corrections publish as dated addenda on this page.

This analysis is the work Janus Compliance does for clients before the incident. For a fixed-scope read of your own EU AI Act Article 50 exposure, see the Article 50 teardown; for ongoing agent governance, Janus DPO-as-a-Service. New entries are delivered free through Compliance Engineering on Substack. Browse the full register or the vendor compliance index.