Security firm Mindgard publicly disclosed an unpatched Cursor vulnerability on July 14, 2026, after the flaw sat unfixed for seven months. A malicious git.exe planted in a repository executes automatically the moment a developer opens the project in Cursor on Windows.
Quick Summary – TLDR:
- Mindgard disclosed the flaw after Cursor went more than six months and 197+ new versions without a fix, per Mindgard’s own timeline.
- Cursor searches multiple locations for Git binaries, including the workspace itself, and runs any git.exe planted there automatically, per Mindgard’s technical writeup.
- Mindgard’s proof of concept, a renamed Windows Calculator app, still triggered code execution on April 30, 2026, against Cursor version 3.2.16.
- Cursor counts more than 7 million active users and over 1 million paying subscribers, per Mindgard.
- Cursor has not issued a public statement.
Mindgard Goes Public on Cursor’s Unpatched Flaw
Mindgard, a security research firm, first identified the vulnerability on December 15, 2025, and reported it to Cursor the same day. More than six months and 197+ new Cursor versions later, the flaw still sat in the latest tested build, the company said. Cursor is one of the most popular AI-assisted development environments, with more than 7 million active users, according to SecurityWeek.
A developer only needs to open a repository in Cursor on Windows that contains a malicious git.exe in its root folder for the program to run automatically. There are no clicks, prompts, approval dialogs, or warnings.
Open a repository in @cursor_ai on #Windows and, if a file named git.exe is sitting in the project root, #Cursor runs it. No click, no approval dialog, no warning that anything in the folder is about to execute.
— Offensive Lab (@OffensiveLab) July 15, 2026
Whatever that binary does, it does as you, with your source, your… pic.twitter.com/U5fWWm4dNf
How the Git.exe Exploit Works?
When loading a project, Cursor searches multiple locations for Git binaries, and one of those locations is the workspace itself. If an attacker planted a malicious `git.exe` in the repository root, Cursor will execute it automatically as part of its path resolution logic without warning, approval, or even an indication that executable content from the repository is about to run.
Mindgard demonstrated the flaw by renaming the Windows Calculator application to git.exe and placing it in a repository’s root folder. Simply launching Cursor against that repository was enough to execute it, and the binary keeps re-executing on a cadence for as long as the project stays open, not just once at launch.
In a live attack, Calculator would be swapped for attacker-controlled code running with the same privileges as the person who opened the project.
Seven Months of Silence
Cursor’s chief information security officer invited Mindgard into the company’s HackerOne bug bounty program in January 2026, where the report was resubmitted and confirmed as reproducible. The company has not responded since. SecurityWeek separately emailed Cursor for a statement and says it will update its report if the company responds.
But coordinated disclosure only works when there is coordination. Seven months after initial disclosure, we have no indication that users are being protected, that remediation is underway, or that affected organizations have been informed. And at this point, withholding information no longer serves users, it serves silence. Mindgard wrote in its disclosure post.
Neither Mindgard’s writeup nor SecurityWeek’s report references a CVE identifier for the bug, a sign of how far this case has drifted from standard coordinated-disclosure practice.
What Cursor Users Should Do Now?
On managed Windows fleets, Mindgard recommends AppLocker or Windows App Control policies that deny execution by file path rather than file hash, since an attacker-controlled git.exe can carry any hash. A rule scoped to a pattern such as %USERPROFILE%sourcerepos*filename.exe blocks execution from inside developer workspace folders. Windows has no built-in way to block a child process only when a specific parent launches it, so catching this pattern generally needs EDR (endpoint detection and response) tooling.
Individual developers should open untrusted repositories only inside an isolated VM, Windows Sandbox, or another disposable environment until Cursor ships a fix, and should not rely on file-hash blocklists, since a swapped binary’s hash changes with every attacker. These steps cut exposure rather than remove it, since only Cursor can close off git.exe resolution to the workspace folder for good.
SQ Magazine’s Takeaway
The bigger signal here is not the exploit itself but the seven-month gap between a fully reproducible report and any sign it mattered. Coding agents are increasingly trusted with direct access to repositories, terminals, and credentials, which raises the stakes of a slow triage pipeline well past a single missed patch.
When the process built to turn a bug report into a fix stalls for seven months on one of the simplest bugs a researcher can hand a vendor, the coordination gap becomes the real exposure, not just the git.exe path.
Watch whether Cursor ships a fix or even a public statement now that the flaw is out in the open. If HackerOne engagement resumes only after the public disclosure, that says as much about how AI coding vendors triage security reports at scale as the bug itself does. Security teams running Cursor on Windows should treat AppLocker path rules or sandboxed repositories as a standing control, not a stopgap, until Cursor confirms a fix and gives the bug a public tracking reference.
