Cursor Sandbox Escape Shows AI Agents Need Kernel Boundaries
Two critical bugs in Cursor's command sandbox let an attacker-controlled AI agent write outside it and reach RCE. Both are fixed in Cursor 3.0.
Researchers at Cato AI Labs uncovered two critical flaws in Cursor's agent command sandbox: CVE-2026-50548, a path traversal via an agent-controlled working_directory, and CVE-2026-50549, an unsafe fallback in symlink canonicalization. Both scored above 9 on CVSS and required nothing from the victim beyond a compromised agent acting on a prompt-injected task; both could escalate into full unsandboxed remote code execution by overwriting the cursorsandbox helper itself.
The shared root cause is that the sandbox judged whether a path stayed inside the workspace using application-layer, user-space string logic rather than kernel enforcement. A trusted-but-attacker-supplied directory field, or a canonicalization step that fails open, was enough to defeat the check — the classic weakness of confinement enforced by the same process it's meant to contain.
Cursor 3.0 fixes both issues correctly: write access no longer depends on an agent-controlled directory, and unresolvable paths are now blocked instead of falling back into the workspace. The piece also discusses how a kernel-enforced outer boundary (via Landlock-based tooling like h5i env) adds defense-in-depth against this exact class of bug, since the filesystem decision is made by the kernel on the resolved path rather than by application logic — though such tooling doesn't patch Cursor or stop prompt injection itself; upgrading remains the real fix.
For engineers, the takeaway is that running AI agents against untrusted input (repos, issues, MCP context) shouldn't rely solely on application-level sandboxes. Kernel-backed isolation — filesystem allowlists, network namespaces — is worth layering on top for higher-risk agent workflows.