Cursor RCE via Prompt Injection: The Agentic IDE Attack Surface

Two critical vulnerabilities in Cursor IDE, tracked as CVE-2026-50548 and CVE-2026-50549, allow an attacker to break out of Cursor's command execution sandbox and achieve remote code execution with no user interaction. Both carry a 9.8 CVSS score. Both were patched in Cursor 3.0, released April 2. Cato AI Labs, which found the flaws and named them DuneSlide, confirmed it is disclosing similar issues across other popular coding agents. This is a class problem, not a Cursor problem.

What the sandbox was supposed to prevent#

Cursor's 2.x line ran agent terminal commands inside a sandbox by default. The design goal was narrow: an agent misdirected by prompt injection could not, on its own, write outside the current project directory. That boundary was the difference between "the agent did something wrong" and "the agent compromised the developer's machine." Most agentic IDE workflows were built assuming that boundary held.

DuneSlide is about what happens when it doesn't.

How the two CVEs work#

CVE-2026-50548 exploits a parameter. Cursor's run_terminal_cmd tool accepts an optional working_directory argument. The sandbox already permits writes inside whichever directory is set there. A prompt injection payload, delivered through an MCP server response or a poisoned web search result, can steer the agent into setting working_directory to an attacker-chosen path outside the project root. Aimed at /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox on macOS, the attack overwrites the sandbox helper itself. Every subsequent command in that session runs with no sandbox at all. Shell startup files like ~/.zshrc are also valid targets.

CVE-2026-50549 exploits a fallback in path resolution. Before writing, the Cursor agent canonicalizes the target path to confirm it stays inside the workspace. The vulnerability is in what happens when canonicalization fails: the agent falls back to the original, unvalidated symlink path and writes without approval. Per Tenable's CVE entry, a malicious agent can force canonicalization to fail by pointing a symlink at a path that does not exist or lacks read permissions, then write through that symlink to an arbitrary location. The result is the same: the cursorsandbox helper gets overwritten, the sandbox is neutralized, and subsequent commands execute unsandboxed under the developer's full privileges.

Cato Networks researchers noted: "The exploit requires no prior user privileges or specific user interaction. It is triggered 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."

Why this is not a Cursor-specific bug#

The underlying failure is structural. Any agentic IDE must satisfy three conditions simultaneously: the agent reads from untrusted sources (MCP servers, web results, fetched READMEs, repository issues), the agent has tools that touch the host (shell, file system, network), and the model cannot reliably distinguish user instructions from instructions embedded in fetched content. Those three conditions do not change when the editor changes.

Cato confirmed it is in the process of responsibly disclosing vulnerabilities in all popular coding agents. The framing is deliberate: CSO Online reported that the researchers describe this as "a native flaw in LLMs and AI-assisted IDEs affecting more than just Cursor." Cursor shipped a sandbox with two holes. Other editors will have different holes in different safety layers.

The Mitiga Labs analysis from June 22 reinforces this. A fake take-home coding assessment repository, containing no traditional malware, used indirect prompt injection through files an agent trusts by default (CLAUDE.md, .cursor/rules, README, MCP config) to harvest AWS credentials and exfiltrate data in under two minutes. The attack vector is a text file. It works across tools.

The review perimeter has moved#

This matters for code review in a specific way. Traditional static analysis looks at what code does when it runs. It does not scan for instruction-laced strings embedded in comments, READMEs, or issue bodies, because historically those strings did nothing. They were documentation. An agent reads documentation and acts on it.

A repository that passes every SAST check can still carry a payload in a # TODO comment or a CONTRIBUTING.md section. That payload does nothing until an agentic reviewer processes the file. At that point, it executes. The attack surface now includes any text the agent ingests, not just code the compiler processes.

As covered in the bottleneck moved, the cost of writing code dropped to near zero while the cost of trusting it did not. DuneSlide adds another dimension: the cost of reviewing code now includes the risk that the review agent itself becomes the execution vector.

What autonomous code review needs to check#

Hyrax reviews every file in a repository across six agent domains, including security. The DuneSlide disclosure adds a concrete scan requirement: identify strings in non-executable files (READMEs, comments, config documentation, issue templates) that carry instruction syntax targeting agent behavior. Patterns include role-override instructions ("ignore previous instructions"), credential harvesting directives embedded in setup documentation, and symlink creation sequences hidden inside onboarding scripts.

Traditional SAST does not flag these because they are not code paths. They are social engineering payloads for agents. The distinction matters less now that agents are the reviewers.

Hyrax submits the PR. The developer merges. That separation, agent proposes and human decides, is one structural mitigation against the class of attack DuneSlide describes. An agent that cannot auto-merge cannot be weaponized to auto-merge a compromised payload.

Hyrax is live at hyrax.dev.