Cursor 3.0 fixed two flaws that allowed an AI coding agent to write outside its assigned project and tamper with the sandbox meant to contain it. Cato AI Labs named the pair DuneSlide. They are tracked as CVE-2026-50548 and CVE-2026-50549.
Both bugs affected Cursor Desktop releases before 3.0. According to Cato’s research, an attacker could place hidden instructions in content that the agent later consumed, such as a response from an MCP server or a poisoned search result. Those instructions could steer Cursor toward either of the vulnerable path-handling routines. From there, the researchers demonstrated an arbitrary file write under the developer’s account and a route to unsandboxed command execution.
There is no public evidence that either flaw has been exploited in an intrusion. The research is still worth close attention because it connects prompt injection to ordinary desktop security failures. The model supplied the instructions, but the code around it supplied the authority.
The prompt supplied the route
Cursor 2.x ran agent-initiated terminal commands in a sandbox by default. That design reduced the need for a user to approve every command while limiting where automatic commands could write. DuneSlide found two ways for an agent to defeat the workspace restriction.
The attack begins with content, not an executable. A developer can ask an ordinary question and cause the agent to retrieve text controlled by someone else. The developer may never see the embedded instruction. Once it enters the model’s context, the agent can translate it into a tool call and operate under the developer’s local account.
That sequence changes the practical risk of prompt injection. Instead of merely corrupting an answer, the attacker can reach source code, credentials and local tooling through the agent. Defenders need to account for the authority the client makes available whenever it processes untrusted text.
Figure details
Attacker-controlled text from an MCP response or poisoned web result enters the Cursor agent's context. CVE-2026-50548 lets the agent set working_directory outside the project, which expands the sandbox write policy and permits the cursorsandbox helper to be overwritten. CVE-2026-50549 uses an in-project symlink whose destination cannot be resolved; Cursor accepts the original path, follows the symlink to an external target, and permits that file to be overwritten. Later commands can then run without the intended sandbox restriction.
CVE-2026-50548 trusted an agent-controlled directory
Cursor’s sandbox granted write access to the current working directory of a command. The default was the project root, which kept normal agent activity inside the open workspace. The run_terminal_cmd tool also accepted an optional working_directory parameter.
Cato found that the agent could set that parameter to a different location. Cursor then added the chosen path to the sandbox’s writable list. An injected instruction could therefore move the command’s working directory outside the project and gain write access there under the user’s privileges.
The researchers targeted Cursor’s cursorsandbox helper on macOS. Replacing that helper caused later commands in the same chain to run without the intended restriction. The NVD entry for CVE-2026-50548 confirms that versions before 3.0 were affected and that overwriting the helper could lead to unsandboxed remote code execution.
This failure is easy to recognize once it is laid out: the component being constrained could influence the value that defined its own writable area. The sandbox existed, but its policy accepted an unsafe input from the agent it was supposed to contain.
CVE-2026-50549 failed open on a symlink
The second flaw lived in Cursor’s file-write path checks. Before writing a file, Cursor attempted to canonicalize the destination. Resolving the path first should reveal whether a symlink inside the project ultimately points somewhere on the host filesystem.
The unsafe behavior appeared when that resolution failed. Cursor fell back to the original path and allowed the write without approval. Cato created a symlink inside the workspace that pointed outside it, then forced canonicalization to fail by using a missing destination or removing read permission from part of the path. The unresolved path still appeared to belong to the project, while the actual write followed the symlink to the external target.
The same sandbox helper could then be overwritten. Cursor fixed the behavior in version 3.0.
Symlink bugs are hardly new. What changed here was reachability. The agent could create the link, choose the path and issue the write after reading attacker-controlled material. Operations that once required local footholds could be assembled through an instruction channel.
A coding agent inherits the workstation
Developer laptops tend to accumulate powerful credentials. Source repositories, package registries and cloud accounts are close at hand because developers use them throughout the day. SSH keys, browser sessions and Kubernetes configuration may also be available to processes running under the user’s identity.
An agent with terminal access sits on top of that environment. Its effective reach depends on the filesystem, command runner and connected services provided by the client. A model that is tricked into a bad decision is only part of the incident path. The surrounding application determines whether that decision becomes a stray answer, an unauthorized file write or code execution on the host.
DuneSlide also complicates a familiar procurement question. Asking whether a coding tool has a sandbox is insufficient. Teams need to know which values build the policy, whether the agent can influence them and how the client behaves when a safety check cannot reach a clean answer. A permissive fallback can erase much of the protection advertised by the control.
MCP connections deserve the same scrutiny. Cato used an MCP response as one example of an injection source, alongside poisoned web content. Data returned by connected services therefore sits inside the agent’s instruction surface, even when the server itself is legitimate.
Issue trackers, documentation systems and support tools often accept content from people outside the engineering team. If an agent can read that material and operate local tools in response, those systems have a path into the development environment. Their permissions and provenance belong in the threat model.
Check the client and the authority around it
The immediate fix is straightforward: find Cursor Desktop installations older than 3.0 and update them. The inventory should include personal devices used for company development, where managed software reporting is often incomplete.
After patching, review the authority available to coding agents. Identify clients that can execute terminal commands or write files without a separate approval. Record the external services that can feed them context. Pay particular attention to agents running in shells that already hold cloud, repository or package credentials.
Product testing should cover the failure paths that DuneSlide exposed. Attempt to set tool parameters outside the approved workspace. Exercise writes through symlinks and paths that cannot be resolved. A failed policy or path check should stop the action and leave an audit trail.
Reducing ambient access limits the damage if a client fails again. Keep production credentials away from general development sessions where practical. Scope tokens to the task and repository. Use isolated workspaces for unfamiliar code, external issue triage and other jobs that invite untrusted context.
Cursor shipped a sandbox and still left enough room for an injected prompt to reach the host. Its security boundary included every piece of code that turned model output into an action. Defenders should test that entire path with the same suspicion they apply to any other command runner.