CVE-2026-50549: Cursor agent could write outside the workspace via a symlink and escape the sandbox
Before 3.0, Cursor's check that agent file writes stay inside the workspace failed open. A malicious agent (for example one steered by prompt injection) could use an in-workspace symlink to write anywhere the user could, without approval, including over Cursor's own sandbox helper.
What it is
Cursor advisory GHSA-3v8f-48vw-3mjx: before a Write, the agent canonicalizes the target path to make sure it's inside the workspace. If canonicalization fails, it fell back to the original path and wrote without asking.
An attacker-controlled agent could create a symlink inside the workspace that points outside it, then make canonicalization fail, either because the target doesn't exist yet or because read permission was removed from the path. The write then went through the symlink to an arbitrary location.
Impact per Cursor: arbitrary file writes outside the workspace as the user, enabling non-sandboxed remote code execution, for example by overwriting the cursorsandbox helper so later commands run unsandboxed, "with no user interaction beyond a benign prompt".
Fixed in Cursor 3.0. A path that can't be resolved is now treated as untrusted, and the write is blocked. Credit: Maor Dokhanian, Cato AI Labs.
How to check
- Cursor → About: confirm you're on 3.0 or later on every machine, including team laptops that don't auto-update.
- If you ran agents on untrusted repos or content on an older version, look for unexpected symlinks in your projects that point outside the workspace.
How to fix
- Update Cursor to 3.0 or later.
- Treat repo contents, issues, docs and web pages the agent reads as untrusted input, and keep approvals on for agents working with them.
# List symlinks in a project that point outside it
find . -type l -exec sh -c 'for l; do t=$(readlink -f "$l" 2>/dev/null || readlink "$l"); case "$t" in "$PWD"/*) ;; *) echo "$l -> $t";; esac; done' sh {} +