Cursor Launches git.exe from Repository Root on Windows
8 Min. Read time
Mindgard describes a simple, serious flaw in Cursor on Windows: If a file named git.exe resides in the project root, the IDE launches it when opening the repo without prompting or warning, with the developer’s privileges. Disclosure since December 2025, public Full Disclosure on 14. July 2026, according to research still unpatched.
Key Takeaways
- No click needed. Opening a repo is enough if git.exe is in the root.
- Months without fix. Report 15.12.2025, Full Disclosure 14. July 2026, 197+ versions later according to Mindgard still present.
- Shadow-IT risk. AI IDEs should be included in software BOMs and whitelists.
- Mitigation now. AppLocker/App Control against Workspace executables; untrusted repos only in sandbox or VM.
Related:TrapDoor Supply-Chain on npm/PyPI / Source Code Leaks and Patch Bypass
The Bug in a Paragraph
What is the Cursor-git.exe Bug? When loading a project, Cursor searches for Git binaries in multiple locations, including the workspace. A git.exe placed in the repository root is executed as part of the path resolution. Process-monitor traces show Cursor.exe launching git rev-parse –show-toplevel with the workspace binary. Mindgard’s PoC exploits Windows machines that rename calc.exe to git.exe. The calculator starts and respawns while running.
Definition · Binary Planting in the IDE
The Integrated Development Environment (IDE) also searches for tool binaries within the workspace. A compromised repository supplies git.exe in the root. When opened, the IDE launches the attacker’s code in the developer’s user context.
No prompt injection, no model jailbreak. Binary planting in the workspace. For attackers, a single compromised repository suffices: clone it, open it in Cursor, and the code runs in the developer’s user context. Often granting access to tokens, SSH keys, and internal packages.
Timeline and Vendor Silence
Mindgard reported on 15. December 2025 to security-reports@cursor.com. Via HackerOne and the CISO channel, confirmation and reproduction were obtained, after which, according to the research, there was long silence. On 14. July 2026, full disclosure followed because coordinated remediation did not occur. As of the research publication: no patch, no public advisory from the vendor.
For CISOs, this is the second finding besides the bug: vendor SLA and disclosure hygiene belong in the evaluation of AI coding tools. Productivity alone is not a trust argument. Cursor is shadow IT in many engineering organizations. The fix horizon is unknown.
What Companies Must Do Until the Fix
Until a vendor fix takes effect, the mitigation stays in place: inventory Cursor users on Windows, enforce policies for untrusted repositories, and deploy endpoint controls that block malicious workspace executables. This checklist represents the baseline security requirements for chief information security officers (CISOs) and engineering leads.
Secure Cursor on Windows
- ✓Inventory: Which teams use Cursor on Windows (license, MDM, downloads)?
- ✓Policy: Do not open untrusted repositories in the production IDE; use only a VM or sandbox
- ✓App Control: Block execution of executables from developer workspace paths
- ✓EDR: Alert when Cursor.exe spawns unexpected child processes from repository paths
- ✓Software-BOM: Treat AI IDEs like any build tool, with owner, version, and exit criteria
AppLocker or Windows Defender Application Control (WDAC) should enforce path-based rules rather than hash-based ones; attackers can change hashes. Generally, do not allow any executables from workspace roots, not just git.exe. Binary planting is a known pattern across multiple AI IDEs. Those who demand “no CVE in the scanner” miss the risk. Primary source: Mindgard blog, 14.07.2026; cross‑checks also cited by Dark Reading and The Hacker News.
Frequently Asked Questions
Every question is locked. A tap unlocks the answer.
Is it relevant for macOS and Linux?
The described exploit targets Windows and git.exe in the repository root. Other platforms are to be evaluated separately. Windows developers are the clear hotspot.
Is it enough to block git.exe?
It is the current trigger. Path-Resolution can check additional tool names. Better: generally prohibit executables from workspace roots.
Is this the same as CVE-2026-26268 (Git Hooks)?
No. 26268 concerns hidden Git hooks according to reports. The Mindgard case is Binary Planting of git.exe in the root. Different mechanism, same outcome: Code Execution.
What do we require from the vendor?
Patch, Advisory, a clear Search-Path-Policy without Workspace-Exec, and transparent SLAs for Criticals in Bug-Bounty.
Primary source?
Mindgard Blog “Cursor 0day: When Full Disclosure Becomes the Only Protection Left” (14.07.2026).
Lesetipps der Redaktion
LesetippSharePoint-JWT-Bypass öffnet On-Prem-SitesLesetippBitLocker-Bypass bei physischem ZugriffLesetippNihon Kotsu: Dispatch fällt nach Malware
Mehr aus dem MBF Media Netzwerk
cloudmagazinAWS Sovereign Cloud: was wirklich getrennt istMyBusinessFutureDigitaler Produktpass: Was Hersteller tun müssenDigital ChiefsToken-OPEX: Inference steuert, nicht das Seat-Budget
Bildquelle: KI-generiert (Juli 2026)
