MediumA Cursor Sandbox Escape Shows Why AI Agents Need Kernel Boundaries | by Hideaki Takahashi | Jul, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

What happened<br>Root cause<br>Impact<br>How h5i env changes the outcome<br>What h5i env does not do<br>Takeaway<br>Sources

A Cursor Sandbox Escape Shows Why AI Agents Need Kernel Boundaries

Hideaki Takahashi

6 min read·<br>Just now

Listen

Share

Cursor shipped a sandbox for agent-run commands, then two path-handling bugs let a malicious agent write outside it and reach full remote code execution.<br>What happened<br>Cursor confines the commands its agent runs to a workspace sandbox, with the cursorsandbox helper granting write access to the command's working directory. Cato AI Labs (with Maor Dokhanian on the second finding) reported two ways an agent could write outside that boundary. Both were disclosed in June 2026, both are rated Critical (CVSS 4.0 9.3, CVSS 3.1 9.8), and both are fixed in Cursor 3.0. Neither needs anything from the victim beyond acting on a benign-looking prompt from an agent that is itself under attacker control, for example through prompt injection in a repository, an issue, or MCP-supplied context.<br>CVE-2026–50548 , path traversal via working_directory (CWE-22). The sandbox grants write access based on the command's working directory, and that directory was agent-controlled. By setting working_directory to a sensitive location, the agent could make the sandbox include writable paths outside the intended workspace and write arbitrary files under the user's privileges. Overwriting the cursorsandbox helper itself means every later command runs unsandboxed, so a single arbitrary write converts into non-sandboxed remote code execution.<br>CVE-2026–50549 , symlink canonicalization fallback (CWE-59). Before writing, Cursor canonicalized the target path to confirm it stayed inside the workspace. When canonicalization failed, it fell back to the original in-workspace path and wrote without approval. An agent could create a symlink inside the workspace that points outside it, then force resolution to fail on purpose (the target does not exist yet, or its read permission is removed). The failed check dropped into the unsafe fallback, and the write followed the symlink to the external target. The same cursorsandbox overwrite turns it into unsandboxed RCE.<br>Two different bugs, one shared shape: a path the application believed was inside the workspace resolved, at the filesystem, to somewhere it was not.<br>Root cause<br>Press enter or click to view image in full size

Both flaws are failures of path-string reasoning inside the application. The sandbox decided what was in-bounds by examining paths in user space: a parameter it trusted (working_directory), or a canonicalization step it performed and then mishandled on failure. An attacker who can influence those inputs, an agent-controlled directory field, a symlink plus a deliberately failing resolve, moves the effective write target without the check noticing.<br>This is the classic weakness of an application-layer confinement: correctness depends on the program reasoning perfectly about every path, every parameter, and every failure mode before it calls open(). A single "when in doubt, use the original path" fallback, or one trusted-but-attacker-supplied field, is enough to escape. The sandbox and the thing it is trying to contain share the same privilege and the same view of the filesystem, so the boundary is only as good as the code that draws it each time.<br>Cursor 3.0 fixes both correctly: the sandbox no longer grants write access based on an agent-controlled working directory, and an unresolvable target path is now blocked instead of falling back into the workspace. Update to 3.0 or later. That is the fix.<br>Impact<br>Arbitrary file write under the developer’s own privileges, escalating to remote code execution the moment the cursorsandbox helper (or any other trusted host file) is overwritten. From unsandboxed execution an attacker reaches source, credentials (~/.ssh, ~/.aws, .env), the rest of the repository, and any network the developer can. The trigger is ordinary agent use on untrusted input, precisely the review-and-triage work where you point an agent at code, issues, or MCP context you did not write.<br>How h5i env changes the outcome<br>Press enter or click to view image in full size

The lesson is not “distrust sandboxes,” it is that a confinement enforced by the same process it confines can be argued out of its own rules. h5i env adds an outer boundary enforced by the kernel, not by application path logic. When you run the agent inside a supervised box, the filesystem allowlist is a Landlock rule the kernel checks against the actual resolved object of every open(), so the two tricks above have nothing to fool.<br>h5i env create cursor-triage --isolation supervised # fails closed if the host can't enforce it<br>h5i env shell cursor-triage -- cursor-agent ""<br>h5i env diff...