Cursor can run a repository's `git.exe`. It says the repo is the trust boundary

Security company Mindgard published details of what it called a Cursor 0day on July 14, 2026. The issue is unusually simple: place a malicious file named git.exe in the root of a repository, open that repository in Cursor on Windows, and the editor may execute the file without a prompt. In a real attack, the result is arbitrary code execution under the developer's account.

Mindgard demonstrated it with Windows Calculator renamed to git.exe. Cursor launched the program while trying to locate Git, then continued launching it while the project remained open. The researchers last verified the behaviour on April 30 with Cursor 3.2.16.

Mindgard says it first reported the issue on December 15, 2025. An automation failure delayed its invitation to Cursor's private HackerOne program; after Mindgard resubmitted the report in January, it was closed as informative and out of scope, then reopened after a challenge and successful reproduction. Update requests went unanswered through the following months, and Mindgard published its findings on July 14, roughly seven months after the initial report.

Cursor's public position arrived in stages. A spokesperson told Dark Reading on July 13 that the company was addressing the issue and would get back to Mindgard. Cursor's fuller response on July 15 did not announce a change to the lookup behaviour. Instead, the company said the report was outside its bug bounty program because repositories and other workspace inputs are part of a shared-responsibility model. It pointed customers toward Workspace Trust, which can place untrusted folders in a restricted mode when enabled.

That response makes this more interesting than an ordinary vulnerability disclosure. Cursor and Mindgard disagree about where the security boundary should be.

Opening a repository is not usually treated like running it

The attack has narrow requirements. It only affects Windows, according to Cursor. The user must open a repository or directory containing an executable named exactly git.exe at its root. An attacker does not gain access merely by placing a link on a website or sending a prompt to Cursor.

Still, cloning a repository and executing its code are normally separate decisions. A developer may open an unfamiliar project to review a pull request, inspect a dependency, reproduce a bug, or perform a security audit. The repository can contain build scripts and binaries, but the expectation is that those files remain inert until the developer runs something or approves a tool that does.

In Mindgard's demonstration, the executable ran as part of Cursor's ordinary Git discovery. Process Monitor showed Cursor invoking the repository's git.exe with git rev-parse --show-toplevel. The user did not select that binary or start a build.

Cursor is not alone in this bug class. Cymulate documented in June that GitHub Copilot CLI on Windows could execute a workspace git.exe during startup, before displaying its folder-trust prompt.

This is why the exact trust boundary matters. A repository may be malicious. That does not necessarily mean every program used to inspect it should treat its contents as executable tooling before asking the user.

Cursor considers the repository an input the customer controls

Cursor's position is that customers decide which repositories, prompts, MCP servers, rules and external content enter their environment. Problems that depend on a malicious input already being present generally fall outside its bug bounty scope.

There is some practical logic to that argument. Modern IDEs do more than display text. Language servers, extensions, formatters, tasks and build tools can all execute project-related code. Workspace Trust exists because opening an unfamiliar project in a development environment is not as passive as opening a text file.

The awkward part is that the control only helps when it is enabled and the folder remains untrusted. Cursor says organisations can enforce Workspace Trust through mobile device management. Cursor also acknowledged that it failed to close the loop with Mindgard promptly. With the timeline now public, that is a fairly specific admission about how the report was handled.

The Hacker News discussion split mostly over severity, not over the fix itself. Some commenters noted that the exploit still requires a malicious binary to reach the machine. Others pushed back that cloning an unfamiliar repository, or having an agent fetch code, is exactly how that binary could arrive. A separate line of discussion went to the design issue directly: why should Git discovery consider the workspace at all, rather than resolve an installed binary from a trusted location? The r/programming thread centred on a plainer expectation: opening a repository should not silently execute one of its files.

The immediate response is mostly operational

Windows teams using Cursor should enable Workspace Trust and enforce it centrally where possible. For repositories that are genuinely untrusted, Mindgard recommends using Windows Sandbox, a virtual machine or another disposable environment. Managed environments can also use AppLocker, Windows App Control or endpoint security rules to prevent executables from running out of workspace directories.

Checking a repository for git.exe before opening it may catch this exact demonstration, but it is not much of a security model. Teams reviewing unknown code need a repeatable isolation policy, particularly when an AI code editor can also run commands, install dependencies and inspect credentials in the development environment.

Cursor has explained why it does not consider the report a bug-bounty issue. It has not yet answered the more useful product question: whether locating a Git executable inside the repository is behaviour worth keeping. That decision will say more about Cursor's trust boundary than the wording of its security response.