TL;DR — Cato AI Labs disclosed two critical vulnerabilities in Cursor IDE collectively named DuneSlide: CVE-2026-50548 (Working Directory Trust Gap) and CVE-2026-50549 (Symlink Check Fail-Open), both rated 9.8 CVSS. They enable zero-click remote code execution via prompt injection — no user click, no approval dialog, no malicious file opened by hand. The agent reads poisoned content from an MCP server, a web search result, or a cloned repository, and the sandbox falls apart. Cursor patched both in version 3.0 (April 2, 2026) before public disclosure, and CVEs were assigned June 5. Every version before 3.0 is vulnerable. More than half the Fortune 500 use Cursor.
Introduction: Why DuneSlide Is Different
Cursor IDE is not a toy. The company claims over half of the Fortune 500 use it, which makes the blast radius of DuneSlide one of the largest of any AI vulnerability disclosed in 2026 — not because the bugs are novel in isolation, but because they weaponize the architecture of AI-assisted coding itself.
Most IDE vulnerabilities require the victim to do something dangerous: open a crafted file, install a malicious extension, or click a link. DuneSlide requires none of that. The attack chain begins the moment Cursor’s agent reads something — a web page it fetched for you, an MCP tool response from a connected server, a pull request diff it’s reviewing — and then follows the hidden instructions embedded inside. The agent’s own tools become the attacker’s delivery mechanism.
(Source : The Hacker News — Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox and Run Commands)
The Cursor 2.x line had introduced a terminal sandbox specifically to prevent prompt injection from escalating to code execution. DuneSlide is the answer to that defense: a way to escape the sandbox using nothing more than the agent’s own tool parameters and file-system operations. In security terms, it’s a classic case of the defense creating a new attack surface, and the attacker finding the seam.
The Two CVEs in Detail
CVE-2026-50548: The Working Directory Trust Gap
The first vulnerability exploits how Cursor’s sandbox decides what is safe to write. When Cursor 2.x runs a terminal command inside its sandbox, it constructs an allow-list of writable paths. By default, the working directory is the project root — reasonable. But the run_terminal_cmd tool accepts an optional working_directory parameter, and when the agent sets it to a non-default value, Cursor adds that path to the writable set without validation.
(Source : NVD — CVE-2026-50548 Detail)
An injected prompt can steer the model into a call like this:
{
"tool": "run_terminal_cmd",
"command": "cp /tmp/payload ~/.zshrc",
"working_directory": "/Users/victim"
}
The sandbox sees a “legitimate” working directory parameter and grants the write. The attacker can now drop a file into the user’s home directory — ~/.zshrc, ~/.zshenv, or ~/Library/LaunchAgents on macOS — and those files execute on the next shell or login.
More dangerously, the attacker can overwrite the sandbox helper binary itself at /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox (on macOS). Once that binary is replaced, every subsequent command runs without sandbox restrictions, and the same prompt injection chain delivers full unsandboxed RCE.
(Source : Start Debugging — DuneSlide: Two Cursor Bugs That Turn Prompt Injection Into Zero-Click RCE)
The NVD classifies this as CWE-22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’). The CVSS 3.1 vector — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — tells the story: network-available, low complexity, no privileges, no user interaction, full confidentiality/integrity/availability impact. Under CVSS 4.0, the CNA (GitHub, Inc.) scored it 9.3 with vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.
CVE-2026-50549: The Symlink Check That Failed Open
The second vulnerability is completely independent. Before writing a file, Cursor canonicalizes symlinks to verify the real target sits inside the project directory. The bug is in what happens when that check fails.
If canonicalization fails — because the target file doesn’t exist yet, or because the attacker has removed read permission from a directory in the path — Cursor falls back to trusting the symlink’s in-project path rather than blocking the operation. This is a classic fail-open: when the safety check cannot complete, the system defaults to “allow” instead of “deny.”
(Source : NVD — CVE-2026-50549)
An injected prompt instructs the agent to create a symlink inside the project that points to the cursorsandbox binary outside the workspace. The canonicalization check fails (the helper binary may not exist as a write target yet, or the path conditions are crafted to fail resolution), and Cursor writes through the symlink. Same outcome as CVE-2026-50548: the sandbox helper is overwritten, and subsequent commands execute without restrictions.
The GitHub advisory for CVE-2026-50549 is tracked as GHSA-3v8f-48vw-3mjx.
The Attack Surface
The injection vectors converge on a common shape. The attacker never types into Cursor. Instead, they plant instructions inside content the agent consumes:
- A poisoned MCP server response — even from an official integration like Linear.app
- A compromised web page returned by Cursor’s browsing/fetch tool
- A malicious README or source file inside a cloned repository
- A pull request diff the agent is reviewing — comments and code are agent-readable
(Source : andrew.ooo — Cursor DuneSlide RCE Vulnerabilities Explained (July 2026))
Once the agent reads the injected content, it interprets the hidden instructions as legitimate tool calls. No user click, no approval dialog. The agent is running — that’s enough.
The Disclosure Timeline: Rejected, Then Escalated
The timeline reveals how unprepared the AI coding industry is for this class of vulnerability:
| Date | Event |
|---|---|
| Feb 19, 2026 | Cato AI Labs reports both vulnerabilities to the Cursor team |
| Feb 23 | Cursor rejects both reports. The justification: Cursor’s threat model does not account for MCP server misuse, even when the MCP server is a standard integration like the official Linear.app workspace |
| Feb 26 | Cato escalates directly to Cursor’s security team. The reports are reopened and triaged |
| Apr 1 | Cursor confirms the working directory fix will ship in Cursor 3.0 |
| Apr 2 | Cursor 3.0 is released with both fixes embedded |
| Jun 1 | Cursor confirms the symlink fix was also in 3.0 |
| Jun 5 | CVE-2026-50548 and CVE-2026-50549 are assigned |
| Jul 1 | Cato AI Labs publishes the DuneSlide disclosure |
(Source : Cato Networks — DuneSlide: Two Critical RCE Vulnerabilities)
The four-day rejection-to-reopening turnaround is the critical window. Cursor’s initial position — that MCP server misuse falls outside its threat model — reflects a widespread assumption in the AI tools space: that external inputs consumed by the agent are not part of the attack surface. DuneSlide proves otherwise. Every MCP connection, every web fetch, every repository clone is a potential injection vector. The threat model that excluded those inputs was the vulnerability.
What “Zero-Click” Means for an IDE
In traditional software, “zero-click” typically describes vulnerabilities that trigger without user interaction — think iMessage exploits where receiving a message is enough. For an AI-powered IDE, the definition is more expansive and more dangerous.
(Source : The Hacker News — Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox)
Cursor’s agent runs continuously. It reads code, fetches documentation, reviews pull requests, and responds to MCP tool calls — all without the developer clicking “approve” for each operation. This automation is the product’s core value proposition, and it’s also the attack surface:
- Every clone of a public repository is a potential trigger — the agent reads the repo contents automatically
- Every MCP server integration is a potential trigger — tool responses flow into the agent’s context window
- Every AI-assisted code review is a potential trigger — PR diffs and comments are agent-readable
- Every web search the agent performs is a potential trigger — fetched pages are raw content
The blast radius in an enterprise is severe. A single compromised developer machine with Cursor connected to SaaS workspaces and cloud infrastructure means the attacker potentially gains access to CI/CD pipelines, internal repositories, and cloud credentials — not just the local filesystem. CISA’s SSVC assessment for CVE-2026-50548 classifies the technical impact as “total” and deems the exploit “automatable,” meaning it can be reliably exploited at scale without per-target adaptation.
(Source : NVD — CVE-2026-50548 Detail, CISA-ADP assessment)
Broader Implications: Prompt Injection as an Unsolved Architecture Problem
DuneSlide is not an isolated bug. It’s the latest manifestation of a structural problem that the AI industry has not yet solved: LLM agents cannot reliably distinguish between “system instruction” and “data content.” Every AI code editor with autonomous tool use has the same shape of attack surface, and every one of them has been hit.
(Source : andrew.ooo — Cursor DuneSlide RCE Vulnerabilities Explained)
Three uncomfortable conclusions follow:
1. Sandboxing matters more than model safety. Cursor’s fix was a stronger sandbox, not a model-side prompt filter. That is the correct call. Anthropic Claude, OpenAI GPT-5.6, and xAI Grok all get prompt-injected regularly — no frontier model has solved this at the inference layer. The defense has to live at the process boundary, not inside the model.
2. Agent tool parameters are attacker-controlled surfaces. When the working_directory parameter of run_terminal_cmd can be set by the LLM, and the LLM’s choice is influenced by content it reads, then working_directory is effectively an attacker-controlled value. Every tool parameter that the agent can modify becomes part of the attack surface. The industry needs to treat agent tool inputs with the same suspicion it applies to user-supplied web form fields.
(Source : Start Debugging — DuneSlide: Two Cursor Bugs)
3. The standard threat model for AI IDEs is wrong. Cursor’s initial rejection of the vulnerability — “our threat model does not account for MCP server misuse” — is the entire problem. If your threat model excludes the content your agent reads, your threat model is not protecting your users. Every input source that flows into the agent’s context window is a potential attack vector, including “trusted” integrations.
Cato AI Labs stated it is in the process of responsibly disclosing similar vulnerabilities in all popular coding agents, signaling that DuneSlide is the first public disclosure in a broader wave. If the pattern holds, we should expect CVEs against Devin Desktop, Zed AI, and GitHub Copilot’s agent mode in the coming months.
Enterprise Mitigations: What to Do Now
For individual developers, the fix is straightforward: update to Cursor 3.0 or later. Check your version via Cursor → About Cursor (macOS) or Help → About (Windows/Linux). Every version below 3.0 is vulnerable, and there are no effective workarounds — only the sandbox rewrite in 3.0 closes the attack vector.
(Source : andrew.ooo — Cursor DuneSlide RCE Vulnerabilities Explained)
For enterprises, the picture is more complex. The following mitigations are structural, not point-fixes:
1. Enforce minimum Cursor version via MDM/endpoint management. A single developer running Cursor 2.x in an organization with cloud-connected workspaces is a single point of compromise. Block versions below 3.0 at the endpoint level.
2. Move AI IDEs into devcontainers or Codespaces. Running Cursor inside a containerized development environment means that even a successful sandbox escape is contained to a disposable context. The developer’s host OS remains isolated. This is the most impactful single mitigation for enterprise security teams.
3. Audit and whitelist MCP servers. Every MCP server the agent can call is an attack path. Enterprises should maintain an allowlist, restrict tool permissions to read-only where possible, and treat MCP responses as untrusted input.
4. Add prompt-injection-content scanning to code review pipelines. If your developers use AI-assisted PR review, the PR content itself — including comments from external contributors — should be scanned for injection patterns before the agent processes it.
5. Monitor CVEs across all AI IDEs. Cursor is not uniquely vulnerable. Every autonomous coding agent has the same structural exposure. Security teams should track CVEs for Devin Desktop, Zed AI, GitHub Copilot agent mode, and any other AI coding tool deployed in the organization.
The Pattern: A Year of AI IDE Sandbox Escapes
DuneSlide is the latest — and most severe — in a year-long sequence of prompt-injection-to-RCE vulnerabilities across AI coding tools. The pattern is unmistakable: every autonomous agent feature ships, researchers find a way to escape its sandbox, and the sandbox gets hardened — only for the next escape to target a different seam.
(Source : The Hacker News — Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox)
| Incident | CVE | Date | Vector | Impact |
|---|---|---|---|---|
| CurXecute | CVE-2025-54135 | Aug 2025 | Poisoned Slack message rewrites ~/.cursor/mcp.json, executes even after user rejection |
RCE via MCP config manipulation. Fixed in Cursor 1.3 |
| MCPoison | CVE-2025-54136 | Aug 2025 | MCP config approved once, then silently swapped for malicious commands | RCE via persistent MCP poisoning. Discovered by Check Point Research |
| Cursor Git Hook | CVE-2026-26268 | Feb 2026 | Booby-trapped Git hook in a cloned repo fires when agent runs Git commands | RCE via repository content. Fixed in Cursor 2.5 |
| Aider Web Fetch | — | Feb 2026 | Malicious HTML injected into agent context via web fetch | RCE via fetched content |
| Claude Code MCP | — | Mar 2026 | Third-party MCP server compromise used to run commands | RCE via MCP server abuse |
| Devin Desktop | — | May 2026 | Prompt injection via poisoned repository files | RCE via repo content. Formerly Windsurf |
| DuneSlide | CVE-2026-50548/50549 | Jul 2026 | Zero-click sandbox escape via working_directory parameter and symlink fail-open | Full host compromise, CVSS 9.8 |
The Cursor 2.x sandbox was introduced specifically to address the earlier wave — CurXecute, MCPoison, and the Git hook CVE. DuneSlide is the escape from that defense, targeting not the sandbox’s existence but its implementation details: the trust it placed in agent-controlled parameters and path-resolution edge cases.
Cato AI Labs has stated it is disclosing similar vulnerabilities across other coding agents. The list above is almost certainly incomplete.
FAQ
Q: Am I affected if I’m on Cursor 3.0 or later?
No. Both CVE-2026-50548 and CVE-2026-50549 were patched in Cursor 3.0, released April 2, 2026. Confirm your version via Cursor → About Cursor (macOS) or Help → About (Windows/Linux). If you see 3.0 or higher, you are protected against DuneSlide.
Q: Has DuneSlide been exploited in the wild?
No known exploitation as of publication. Cato AI Labs disclosed the vulnerabilities as research with no evidence of active campaigns. The CISA-ADP assessment for CVE-2026-50548 lists exploitation status as “none.” However, the vulnerabilities are rated “automatable,” meaning reliable exploitation at scale is feasible without per-target customization — so the window between disclosure and potential exploitation is narrow.
(Source : NVD — CVE-2026-50548 Detail)
Q: Does disabling MCP or web fetch tools protect me?
It reduces but does not eliminate the attack surface. Both vulnerabilities can still be triggered via a poisoned repository clone or a PR review — vectors that do not require MCP or web fetch. The only reliable mitigation is Cursor 3.0 or later.
Q: Why did Cursor initially reject the vulnerability reports?
Cursor’s initial threat model (as of February 2026) excluded MCP server misuse, even from standard integrations like the official Linear.app workspace. The rejection was a threat-model decision, not a technical denial — Cursor’s position was that MCP content was outside its security boundary. The escalation on February 26 led the security team to re-evaluate and ultimately agree that MCP and other agent-consumed content must be treated as part of the attack surface.
(Source : Cato Networks — DuneSlide: Two Critical RCE Vulnerabilities)
Q: Is Cursor uniquely vulnerable, or do other AI IDEs have the same problem?
Cursor is not uniquely vulnerable. The underlying issue — LLM agents acting on content they cannot distinguish from instructions — is universal to all autonomous AI coding tools. Cato AI Labs has stated it is disclosing similar vulnerabilities in other coding agents. Devin Desktop, Claude Code, and Aider have all had prompt-injection-to-RCE incidents in the past 12 months. The structural exposure is the same across the category.
Further Reading
- Cato Networks — DuneSlide: Two Critical RCE Vulnerabilities via Zero-Click Prompt Injection in Cursor IDE — Original disclosure by Cato AI Labs, including the full attack chain and timeline
- NVD — CVE-2026-50548 Detail — Official NVD entry with CVSS vectors and CISA-ADP assessment
- NVD — CVE-2026-50549 Detail — Symlink canonicalization vulnerability
- GitHub Advisory — GHSA-3p48-7v9f-v5cw — Cursor’s vendor advisory for CVE-2026-50548
- GitHub Advisory — GHSA-3v8f-48vw-3mjx — Cursor’s vendor advisory for CVE-2026-50549
- The Hacker News — Critical Cursor Flaws Could Let Prompt Injection Escape Sandbox and Run Commands — Coverage including historical context of prior Cursor CVEs
- Start Debugging — DuneSlide: Two Cursor Bugs That Turn Prompt Injection Into Zero-Click RCE — Technical walkthrough of both exploit chains
- andrew.ooo — Cursor DuneSlide RCE Vulnerabilities Explained (July 2026) — Practical guide including version checking and enterprise mitigation steps
- CVE-2025-54135 (CurXecute) — NVD — Earlier Cursor vulnerability by the same research team (then Aim Security)