TL;DR
A repository could execute any command it chose on your machine, as you, the moment you started Cursor's CLI agent in it with
-w. It ran before the workspace-trust dialog, and fired even for users who had explicitly passed--sandbox enabled.
The command sat in a normal tracked file,
.cursor/worktrees.json, so it arrived with an ordinarygit clone. Nothing on that path constrained it: reading~/.ssh, taking cloud credentials from the environment, opening a reverse shell, writing persistence.Cursor shipped a fix for this exact class in 2025, when a repository-supplied
.cursor/mcp.jsondid the same thing (CVE-2025-64109, High, 8.8). The worktree setup path shipped five months later with the same primitive, same impact – remote code execution from a cloned repository.Cursor has since fixed the pre-trust execution: as of
cursor-agent2026.07.23-e383d2b the setup command is gated behind the Workspace Trust prompt and does not run until the workspace is trusted. Earlier builds remain affected. The sandbox behaviour is unchanged.--sandbox enabledstill does not apply to the setup command.We reported it on 2026-07-20. The fix shipped on 2026-07-23. On 2026-07-29 the report was closed as showing no security impact. No security advisory was published, so anyone on an affected build had no way to know that updating closed a pre-trust execution path.
Above: Calculator launches before the Workspace Trust prompt is accepted
Workspace Trust Message
Cursor CLI has a workspace trust gate, and it is explicit about its purpose. The gate exists so that nothing the repository controls runs before the user accepts the ‘Trust this workspace’ prompt. If any code is executed beforehand, it is a flaw, unintended behaviour. This type of vulnerability can be classified as ‘Pre-Trust’ or ‘Untrusted Workspace’: CVE-2025-64109 is a clear example of this.
Above: Cursor Workspace trust prompt
A flag, a JSON file, and the wrong order
Cursor CLI is the terminal version of Cursor's coding agent: you point it at a repository, it reads and edits your code, and it runs shell commands to do that work. Because letting an agent loose on your working tree makes people nervous, it offers isolation. From Cursor's CLI parameter reference:
A fresh worktree has none of your build artifacts, so cursor-agent also runs a setup step when it creates one, by default. That step reads .cursor/worktrees.json out of the checked-out repository and passes its setup-worktree value straight to sh -c. On builds before 2026.07.23-e383d2b it did so without trust.
No parsing, no allowlist, no prompt. Whatever command the repository author set there ran on the machine of anyone who started the agent in that repository with -w, with their user's privileges and their full environment.
The setup step runs under a hardcoded insecure_none sandbox policy. That is Cursor's own name for the setting: in sandbox.json, type accepts workspace_readwrite (the default), workspace_readonly, or insecure_none, which disables the sandbox entirely. The worktree setup path is pinned to that value. A user who passes --sandbox enabled does not change it.
On 2026.07.01-41b2de7 the setup command executed while the terminal was still printing "Running worktree setup commands…", and the trust prompt rendered after that.
Worktree creation and setup ran during workspace resolution, which completed before the code path holding the trust dialog.
Cursor patched this same class in .cursor/mcp.json in 2025
Cursor has handled similar vulnerabilities in the past, in the same directory.
In 2025 a repository-supplied .cursor/mcp.json would auto-start its configured server when a project was opened in Cursor CLI. That became CVE-2025-64109/GHSA-4hwr-97q3-37w2, rated High (CVSS 8.8), patched in 2025.09.17-25b418f. The description states the trigger.
Above: CVE-2025-64109 Summary
Once a victim clones the project and opens it using Cursor CLI, the command to run the malicious MCP server is immediately executed without any warning, leading to potential code execution as soon as the command runs.
The -w worktree path did not exist yet. It arrived in 2026.02.27-e7d2ef6, five months after that fix, and shipped without the gate.
Reproducing it
The PoC is an ordinary-looking repository. The only malicious content is the tracked .cursor/worktrees.json, which fires a calculator:
Cursor's internal git worktree add checked out HEAD including the attacker's .cursor/worktrees.json, the setup value went to sh -c, the calculator opened, and only then did the Workspace Trust prompt render. A command of the repository's choosing had already been executed on the victim's machine, with their privileges, before they were ever asked whether they trusted that repository.
On the current release the same repository and the same command produce the trust prompt first:
The setup command does not run until the workspace is trusted. The calculator never appears before that prompt. The execution was moved behind the gate.
Nine days: reported, quickly patched, closed as Informative
2026-07-20. Reported through Cursor's HackerOne program, report #3877167, with the PoC repository and a screen recording attached. Verified that day against
cursor-agent2026.07.01-41b2de7.2026-07-23.
cursor-agent2026.07.23-e383d2b was released.2026-07-29. The report was closed as Informative, for two stated reasons: that exploitation requires the user to clone or open an attacker-controlled repository, and that the report does not demonstrate bypassing workspace trust.
That same day we re-tested both builds. On 2026.07.01-41b2de7 the calculator still fired before the trust prompt. On 2026.07.23-e383d2b the trust prompt came first and the setup command did not run until the workspace was trusted.
Both reasons are answerable from the public record.
Cursor CLI is a tool for working on repositories. Cloning one is not an exotic precondition, it is the product's entire purpose, and it is the delivery path for very nearly every vulnerability this class of assistant will ever have. It is also the precondition of CVE-2025-64109 itself, the bug Cursor rated High 8.8 and patched. If cloning a repository put a finding out of scope, that CVE would not exist. It describes delivery, not the defect. The one that scored 8.8 and the one that was dismissed differ in which JSON file carried the command, not in what the command could do.
On impact, the setup command runs outside the sandbox even when the sandbox is explicitly enabled. Whatever the disagreement about prompt ordering, a security control that a user turned on and that silently did not apply is not a finding without security impact.
On workspace trust, the recording attached to the HackerOne report, the same one embedded above, shows the command finishing before the prompt renders.
The strongest answer came from Cursor. Three days after the report, by 2026.07.23-e383d2b, the setup command was gated behind the trust prompt, which is the pre-trust fix the report asked for. The behavior was worth changing, and worth changing quickly.
Cursor maintains an advisory process and has used it repeatedly for this type of vulnerability: a file under .cursor/ in a cloned repository reaching a pre-trust execution sink. The mcp.json case above became GHSA-4hwr-97q3-37w2. A permissive .cursor/cli.json handling issue in the CLI became GHSA-v64q-396f-7m79. The worktree setup path got neither an advisory nor an entry in Cursor's July changelog, though the changelog carries little weight on its own: individual CLI builds are not routinely listed there, and 2026.07.23 is unremarkable in that respect. The advisory is the channel that reaches users on affected versions, and it is the one that was not used.
If you use -w, update to 2026.07.23-e383d2b or later. On earlier builds, do not pass -w on a repository you have not read. Updating closes the pre-trust window, not the sandbox gap: on current builds a trusted workspace's setup command still runs unsandboxed, and --sandbox enabled does not change that. To skip the setup step entirely, pass --skip-worktree-setup, which Cursor documents as skipping setup scripts from .cursor/worktrees.json.
How Manifold helps
AI agents do not just answer questions anymore. They read, decide, and act, holding your credentials while they do it. And you trust them to, because that is the point.
The problem is that trust runs on a layer nothing else watches. Your EDR sees a developer tool spawning a shell, which is what developer tools do all day. Your gateway sees a git clone from a host you allow. Neither sees that a JSON file in a repository, not a human and not a model, chose the command that ran, and that it ran before anyone was asked.
Manifold watches that layer: what agents actually do at runtime, not what their permissions say they can. That is where this class of bug becomes visible. Talk to Manifold.
Latest articles
