Post cover image

August 25, 2026

How a Flaw in working_directory Broke Out of the Cursor Agent Sandbox

Summary

By Alice Hsu

7 min read

Summary

On July 1, 2026, Cato AI Labs, a research team under Cato Networks (author Itay Ravia), publicly disclosed two critical vulnerabilities in the Cursor IDE, tracked as CVE-2026–50548 and CVE-2026–50549, both rated CVSS 9.8. The research team named the full attack chain DuneSlide. Cursor states that its users include more than half of the Fortune 500. The two vulnerabilities are independent architectural flaws, both patched in Cursor 3.0 (released April 2, 2026); all versions prior to 3.0 are affected. As of publication, there is no evidence that this attack chain has been exploited in the wild.

DuneSlide matters because it shows that the impact of prompt injection has moved beyond the model output layer into operating-system-level sandbox boundaries and local execution privileges, reaching code paths that were not traditionally considered part of the attack surface. Most prior prompt injection cases were limited to incorrect model output, information disclosure, or improper tool calls. DuneSlide demonstrates that an attacker can poison content an agent later consumes and, step by step, achieve arbitrary local code execution.

Cursor's Sandbox Design and run_terminal_cmd

The Cursor 2.x line by default runs agent-issued terminal commands inside a sandbox automatically, without prompting the user for per-command approval. This is meant to reduce approval fatigue while preventing a straightforward prompt injection from turning directly into RCE.

The sandbox is implemented by dynamically constructing a macOS seatbelt policy for each command, based on that command's parameters, defining the directories the command is allowed to write to. By default the command's working directory is set to the project root, but working_directory is actually an optional parameter on the run_terminal_cmd tool the agent calls. When the LLM assigns this parameter a non-default value, Cursor adds that path to the sandbox's allowed-write list without further validation. The call below is a reconstruction based on Cato Networks' published technical description, not leaked source code:

{
  "tool": "run_terminal_cmd",
  "arguments": {
    "command": "echo pwned > payload",
    "working_directory": "/Applications/Cursor.app/Contents/Resources/app/resources/helpers"
  }
}

Once working_directory points at the directory containing the sandbox helper, the agent's subsequent write operations can land inside that directory rather than being confined to the user's project folder.

CVE-2026–50548, working_directory Parameter Manipulation

The root cause of CVE-2026–50548 is that the sandbox accepts working_directory without verifying the path falls within the project scope, trusting whatever value the agent supplies and permitting the write. An attacker uses prompt injection to steer the agent into calling run_terminal_cmd with a malicious working_directory, which allows writing to an arbitrary path under the user's privileges.

Cato Networks' original writeup lists three categories of actual targets:

  • The sandbox executable itself on macOS, at /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox
  • Shell configuration files, including ~/.zshrc and ~/.zshenv, both loaded every time the user starts a shell or runs a command
  • Login-item / startup directories, such as ~/Library/LaunchAgents on macOS

The most direct path is overwriting cursorsandbox itself. The illustrative flow:

run_terminal_cmd(
  command="cp payload.sh cursorsandbox",
  working_directory="/Applications/Cursor.app/Contents/Resources/app/resources/helpers"
)

Once cursorsandbox is overwritten, every subsequent command issued by the agent runs without sandbox isolation, equivalent to non-sandboxed execution. Writing to ~/.zshrc or ~/Library/LaunchAgents is an alternate path with a delayed trigger, executing malicious code the next time the user opens a shell or logs in, without requiring an immediate overwrite of the sandbox helper.

It is worth stating clearly that prompt injection here is the delivery mechanism, that is, what induces the agent to manipulate working_directory. The technical root cause of the vulnerability itself is the sandbox's lack of path-scope validation for that parameter. The two should be treated as distinct.

The second vulnerability, also rated CVSS 9.8, targets a different layer of protection. Before an agent performs a write, Cursor canonicalizes the target path, resolving symlinks to confirm the actual write location falls within the workspace.

The cause of CVE-2026–50549 is a dangerous fallback in the canonicalization logic: when canonicalization fails, either because the target does not exist or because a directory somewhere along the path lacks read permission, Cursor does not reject the operation. Instead it falls back to the original, unresolved symlink path inside the project directory.

An attacker can exploit this by constructing a write-only symlink, causing Cursor to treat the resolved path as the symlink's own in-project path rather than the external target it actually points to, bypassing the check for whether the destination lies outside the workspace. The steps below are a reconstruction based on Cato Networks' published technical description, not the research team's original line-by-line code:

# Create a symlink inside the project that points at the sandbox helper
ln -s /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox \
      ./project/build_output

# Canonicalization now tries to resolve the real path behind build_output.
# If this resolution fails, either because the target does not exist or
# because a directory along the path lacks read permission, Cursor falls
# back and trusts build_output as if it were an ordinary in-project path.

# When the agent calls the Write tool on build_output, the actual write
# lands on the cursorsandbox executable the symlink points to.

Because the system chooses, on canonicalization failure, to trust a path that merely looks like it is inside the project rather than rejecting the write, an attacker can smuggle the real write target outside the workspace via the symlink. As with CVE-2026–50548, this vulnerability is likewise used to overwrite cursorsandbox to achieve sandbox escape.

Details circulating in secondary coverage, such as environment inheritance or shell wrapper confusion, are not part of the mechanism Cato Networks' original research disclosed and are not used in this piece.

Disclosure Timeline

Cato AI Labs followed a standard responsible disclosure process, which included an episode of the vendor initially declining the reports:

  • 2026–02–19: Both vulnerabilities reported to the Cursor team
  • 2026–02–23: Cursor initially declined to accept the reports, on the grounds that its threat model did not account for MCP server misuse, even when the MCP server itself was an official, ordinary integration (for example, the official Linear.app workspace integration)
  • 2026–02–26: Both reports were escalated directly to the Cursor security team due to severity; the cases were reopened and entered triage
  • 2026–04–01: The Cursor team confirmed the fix for the working-directory vulnerability would ship with version 3.0 (released April 2)
  • 2026–06–01: The Cursor team confirmed the fix for the symlink vulnerability was also included in 3.0
  • 2026–06–05: CVE-2026–50548 and CVE-2026–50549 were formally assigned, confirming the critical severity of both vulnerabilities

What the Attack Chain Means

DuneSlide is not a single isolated vulnerability but a complete attack chain: prompt injection induces the agent to call run_terminal_cmd with malicious parameters, abuses the sandbox's validation gaps around working_directory or symlink paths, overwrites the cursorsandbox component responsible for sandboxing, and ultimately obtains host-level execution, potentially extending to SaaS workspaces connected to that host. Every step in this chain is, on its own, an ordinary part of a development workflow, such as looking up a fix, reading documentation, running a command, or installing a package. The risk is that the agent autonomously chains these steps together without any mechanism for judging the trustworthiness of the source of a given suggestion.

This class of vulnerability shows that the focus of AI agent security is shifting from content review, that is, whether model output is correct or safe, toward classical operating-system security concerns, including sandbox isolation, capability security, and process isolation.

MCP's Role as an Attack Surface

In most agent frameworks that integrate MCP, a tool's return value, and sometimes even its description, is merged directly into the model's context and processed alongside user input. To the model, content returned by a tool and instructions provided by the user are structurally indistinguishable; both are simply part of the natural-language context. This is a core reason prompt injection is difficult to eliminate the way SQL injection can be, through a hard boundary such as parameterized queries: current model architectures contain no hard boundary between trusted instructions and untrusted data.

Conclusion

CVE-2026–50548 and CVE-2026–50549 are two independent implementation flaws. One is a missing parameter validation. The other is an unsafe fallback in an error-handling path. Their immediate causes differ, but they share the same underlying design assumption: the sandbox trusts whatever parameters and paths the agent itself reports.

That assumption is reasonable only if the agent's parameters always come from trusted local logic. It breaks down once the agent's decisions can be steered by content it reads from the outside, such as MCP tool output, search results, or third-party documentation, since the agent has no way to judge how trustworthy that content is. This shared assumption, not the surface-level similarity of "both are sandbox bugs," is why DuneSlide is worth treating as one case study rather than two unrelated bugs.

Three implications follow for teams building or deploying agents with local execution capability. First, trust decisions at a sandbox or privilege boundary should never depend on any parameter reported by the agent or the underlying LLM, including paths, working directories, or filenames; the sandbox layer needs to validate these independently, not accept them from the agent's own output. Second, a path canonicalization failure should default to rejecting the operation rather than falling back to unvalidated raw input. Both vulnerabilities in this disclosure violate that principle, and it is worth auditing for the same pattern in any system that resolves symlinks or relative paths on an agent's behalf. Third, trust evaluation for MCP or tool integrations needs to account for the possibility that a tool's returned content is poisoned, regardless of whether the tool or server itself is official or reputable. In this case the compromise happens in the content, not the connection.

The more durable risk here is architectural, not specific to these two CVEs. As coding agents, and agentic tools more broadly, take on more autonomous, multi-step workflows, the number of code paths where an LLM's output quietly becomes a trusted system parameter will keep growing, and each one is a candidate for the same class of bug. Teams evaluating or building agent runtimes should treat "does this sandbox boundary depend on anything the model can influence" as a check to run every time a new tool, capability, or integration gets added, not a one-time review item.

References