Cursor Auto-Executes Repository Git Executables on Windows
Mindgard disclosed on July 14 that Cursor can automatically execute a malicious git.exe when a Windows developer opens a repository containing that file at its root. Cursor acknowledged the behavior on July 15, called it a shared-responsibility issue outside its bug-bounty scope, and said Workspace Trust can block automatic execution in untrusted folders; it did not announce a patch.
Security firm Mindgard disclosed on July 14 that Cursor's Windows client can execute a repository-bundled git.exe automatically when a developer opens a project. Mindgard says Cursor's Git discovery process can select the workspace copy, allowing a malicious executable at the repository root to run without an approval prompt or warning.
Mindgard first reported the behavior to Cursor on December 15, 2025, and says it last verified the proof of concept on April 30, 2026, using Cursor 3.2.16. The Hacker News noted that the public evidence does not establish whether newer versions behave the same way.
Cursor addressed the report publicly on July 15. The company called it a shared-responsibility issue outside its bug-bounty scope, said the preconditions are limited to Windows and a repository-root file named exactly git.exe, and stated that Workspace Trust can open untrusted folders in a restricted mode that prevents automatic execution. Cursor did not name a patched release or say that the underlying behavior would change.
How the execution path works
Mindgard's proof of concept used the Windows Calculator application renamed to git.exe and placed it in a test repository's top-level directory. The firm says opening that repository in Cursor was sufficient to execute the renamed binary, which Cursor then invoked repeatedly while the project remained open.
Process Monitor output published by Mindgard shows Cursor.exe creating the repository-local process with the command line git rev-parse --show-toplevel. Mindgard describes the cause as workspace-aware Git binary resolution. The Hacker News reported a caveat: the public evidence does not prove whether Cursor explicitly searches the workspace or passes an unqualified git command to Windows and allows the operating system's search order to select the local file.
Either path produces the same observed risk for a user. A repository that appears to be passive source code can contain an executable that the IDE launches during project initialization. The payload runs with the affected developer's Windows privileges.
Scope, response, and mitigations
The attack requires a developer to obtain and open a repository containing the specifically named executable; it is not a drive-by compromise of every Cursor installation. Cursor says macOS and Linux are unaffected and points customers to Workspace Trust, which organizations can enforce through device management. Dark Reading reports that Workspace Trust is not enabled by default and that Mindgard has questioned whether the control intercepts this particular initialization path; the retrieved sources do not document an independent test of that mitigation.
No retrieved source documents exploitation outside the researchers' proof of concept. The sources also do not identify a CVE or a release that removes the behavior.
Mindgard recommends AppLocker or Windows App Control rules on managed systems to block git.exe execution from workspace paths, and isolated environments such as Windows Sandbox or a disposable virtual machine for untrusted repositories. For engineering teams, the broader lesson is to treat repository executables and IDE tool-resolution behavior as part of the software supply-chain threat model, alongside Git hooks, extensions, dependencies, and CI configuration.
Key Points
- 1Mindgard demonstrated Cursor executing a repository-root git.exe when a Windows user opened the project, with the process repeating while the project remained open.
- 2Cursor acknowledged the behavior, described narrow Windows-only preconditions, and pointed to Workspace Trust rather than announcing a patch.
- 3The public evidence was last verified on Cursor 3.2.16 in April, and no retrieved source documents exploitation beyond the proof of concept.
Scoring Rationale
The reported execution path is high impact because opening a poisoned repository can launch code under a Windows developer's identity. Its practical scope is narrower than the original article implied: the repository must contain a root-level git.exe, the public test covered Cursor 3.2.16, Cursor disputes the vulnerability classification, and no in-the-wild exploitation is documented.
Sources
Primary source and supporting public references used for this report.
Practice with real Payments data
90 SQL & Python problems · 15 industry datasets
250 free problems · No credit card
See all Payments problems
