Validated Research Published: Aug 25, 2026

DuneSlide: Two LLM-Controlled Paths Escaped Cursor's Terminal Sandbox

DuneSlide exposed two independent Cursor 2.x flaws. An indirect prompt injection could make the agent authorize an out-of-project working directory, or exploit a fail-open symlink check in the Write tool. Either route could overwrite Cursor's sandbox helper so a later command ran without the intended terminal sandbox. Cursor 3.0 fixed both issues and had already shipped on April 2, three months before Cato's public article.

Indirect Prompt InjectionTool Argument TamperingRuntime IsolationTool AuthorizationAI Coding IDE
5 applicable AIDEFEND defenses
Source: DuneSlide: Two Critical RCE Vulnerabilities in Cursor 
Author: Itay Ravia (Cato AI Labs)
Original article: Jul 1, 2026

Threat Analysis

  • The attacker first needed content the agent would read. Cato used malicious MCP output or poisoned web-search content to steer Cursor. The model did not need the attacker to type directly into the local session.
  • CVE-2026-50548 turned an optional tool argument into a sandbox policy decision. The model selected working_directory for run_terminal_cmd. Cursor then added that directory to the sandbox write allowlist without proving it remained inside the project root.
  • CVE-2026-50549 was a separate fail-open filesystem path. The Write tool tried to canonicalize a destination before enforcing project scope. For a write-only symbolic link whose target did not yet exist, canonicalization failed and Cursor continued instead of denying the write.
  • Both branches reached the same high-impact asset. The injected workflow could overwrite /Applications/Cursor.app/.../cursorsandbox, Cursor's helper for launching sandboxed commands. A later prompt injection then invoked the modified helper and achieved unsandboxed code execution.
  • The first write was not the same as final RCE. Each flaw supplied a route to corrupt the enforcement component; execution occurred when a subsequent command used that component. Keeping those phases separate matters for prevention and detection.
  • The public article described already-fixed software. Cursor's advisories assign CVE-2026-50548 and CVE-2026-50549 to the two paths. Cursor 3.0, released April 2, 2026, contained the fixes before Cato published on July 1.

Applicable AIDEFEND Defenses (5)

AID-H-018.001
Tool Parameter Constraint & Schema Validation
Very High
Make working_directory a required, typed path capability resolved by trusted code under the opened project root. Canonicalize every parent, reject missing or symlinked components, and pass an already-authorized directory descriptor to the tool. This closes both the model-controlled directory escape and the check-then-reopen weakness.
AID-I-001.002
MicroVM & Low-Level Sandboxing
Very High
Place terminal and file tools inside an operating-system sandbox below Cursor's application helper. The profile should deny writes to the application bundle and other host paths even if the model, tool schema, or cursorsandbox wrapper is compromised. This is the strongest independent containment layer for the final RCE path.
AID-H-021.002
Runtime Integrity Enforcement (Signed Configurations)
Very High
Verify the sandbox helper and other security-critical tool files against a signed manifest immediately before use. Refuse execution when the running file differs from the approved release. This targets the shared convergence point where both DuneSlide branches overwrite cursorsandbox.
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
Very High
Inventory Cursor 2.x deployments, rebuild managed images with Cursor 3.0 or later, and verify the two disclosed paths in an isolated regression test. A version label alone is not closure evidence; the deployed population and helper integrity must match the fixed build.
AID-H-017.002
Least-Privilege Tool Architecture
High
Replace ambient file writes with single-purpose project operations that receive bounded object IDs or root-relative paths. A coding agent should not possess a generic primitive that can rewrite its own enforcement helper or arbitrary application files, regardless of what an injected instruction requests.

What Defenders Should Do Now

  • Upgrade every managed Cursor installation to version 3.0 or later. Verify the actual application bundle and deployment inventory, not only the updater's reported state.
  • Disable or restrict agent terminal and generic Write capabilities on hosts that cannot be upgraded immediately. Treat this as an expiring compensating control.
  • Regression-test both branches separately: an out-of-project working_directory, and a write-only symlink whose target does not exist. Both cases must fail before any file is created or modified.
  • Open project roots once with trusted code, resolve file operations relative to that descriptor, and reject symlinks and missing canonical parents. Do not validate a string path and later reopen it by name.
  • Protect the Cursor application bundle and sandbox helper with a lower-level write deny plus signed-file verification immediately before execution.
  • Assume MCP responses and web-search text are untrusted. Record which content proposed each tool call, the normalized parameters, the policy decision, and the file or process effect.

Conclusion

DuneSlide shows why an LLM-selected parameter is part of the security boundary. One branch trusted the model's working directory; the other let a failed path check become permission. Both eventually rewrote the component that was supposed to enforce isolation.

AIDEFEND  places the decisive controls below and around the model: AID-H-018.001 constrains path parameters, AID-H-021.002 protects the enforcement helper, AID-I-001.002 contains the tool even after an application-layer failure, and AID-H-003.010 verifies the fixed build reaches the deployed population.