Technical Context
I rarely see such a down-to-earth and nasty flaw: Cursor on Windows can automatically launch a malicious git.exe if it’s placed in the root of an opened repository. No clicks, no prompt injection, no fancy AI attacks. Just open the folder, and off it goes.
These are exactly the kind of stories I use to assess the maturity of AI implementation in a company. If a development tool breaks because it searches for a binary in the workspace, the problem isn’t in the model or the agent—it’s in the basic product hygiene.
According to Mindgard, the root of the bug lies in the Git search logic: Cursor checks several paths and grabs an executable directly from the project directory. This leads to typical arbitrary code execution with the current user’s privileges. The demo was almost mockingly simple: they renamed Calculator to git.exe, and Cursor ran it silently.
What struck me wasn’t just the code execution but the silence around it. No warning, no confirmation, not even a hint that the IDE is touching a binary from an untrusted repository.
The timing makes it worse. Mindgard reports they submitted the issue on December 15, 2025, then pinged again, including via HackerOne, and the vulnerability was still reproducible at least in version 3.2.16 as checked on April 30, 2026. If these dates are correct, that’s over six months and 197+ releases without a fix.
As of now, July 15, 2026, this isn’t fresh “just discovered” news, but rather a demonstrative breakdown of how full disclosure becomes the last defense when a vendor drags its feet. Cursor told Dark Reading they are “addressing” the problem, but the public disclosure itself says a lot about the response process.
What This Means for Business and Automation
The losers are teams that open external repositories on production Windows developer machines without isolation. The winners are those who long ago separated trusted and untrusted environments and keep AI automation and dev tools running within policy boundaries.
My practical takeaway is simple: all AI IDEs and agents must be included in the same threat model as the browser, email, and RDP client. If a developer pulls code from outside, they need a sandbox, and on Windows at least AppLocker or Windows App Control.
And yes, this doesn’t just hit security; it hits process architecture. I’d reconsider where exactly your AI integration for development lives, who has the rights to open external projects locally, and which binaries can start from the workspace at all.
If your team already relies on Cursor, Copilot, agents, and internal tools, I wouldn’t wait for the next such story. At Nahornyi AI Lab, we help build AI automation and protective constraints so developers don’t lose speed and the business doesn’t pay for one accidentally opened folder. If you’d like, let’s review your setup together and build a solid architecture without unnecessary magic.