A vulnerability in the Cursor code editor lets a malicious repository execute arbitrary code on a Windows machine the instant the folder is opened, with no user interaction and no warning. Security firm Mindgard reported it on December 15, 2025, reproduced it after it was initially dismissed, and then heard nothing from January 20 to July 14 -- a span in which more than 197 versions of Cursor shipped without a fix.
Key facts
- The flaw is remote code execution with zero user interaction: open the folder, the attacker's program runs.
- Reported December 15, 2025. Still unpatched as of July 14, 2026 -- roughly seven months and 197+ releases.
- The report was closed as "Informative" before being reopened when the researcher reproduced it.
- Full technical disclosure published by Mindgard.
The mechanism is almost disappointingly simple, which is what makes it worth understanding. Cursor, like most editors, needs to find the Git program on your system to show which lines you changed and which branch you are on. On Windows it goes looking, and the search starts in the folder you just opened. If a file named git.exe is sitting in that folder, Cursor finds it first and runs it -- because as far as Cursor is concerned, it just found Git.
It is the software equivalent of a building where the front desk hands over the keys to whoever is standing closest to the counter wearing a uniform. Nobody checks where the uniform came from. The attack requires no exploit chain, no memory corruption, no clever timing -- just a file with the right name in the right place, and a developer doing the most ordinary thing a developer does, which is clone a repository and open it.
What elevates this from a bug to a story is the timeline, and Mindgard published all of it. Reported December 15 through the project's own security.txt file, the correct front door. It drew a response from the chief information security officer, then an invitation to the HackerOne bug bounty platform -- both signs the report was being taken seriously. Then it was closed as "Informative," the classification meaning roughly thank you, this is not a vulnerability. The researcher reproduced it. The report was reopened. And then, from January 20, 2026 onward: nothing. Seven months of silence while the product shipped update after update -- 197 of them and counting -- none carrying the fix.
The fair objection is that this is not the end of the world. It needs Windows, and it needs you to open a repository somebody else controls. "Do not run code from strangers" is advice that long predates AI editors, and a developer who clones an anonymous repository and opens it has already accepted some risk. That is true, and it narrows the blast radius considerably.
It also misses what practitioners are actually angry about. The severity argument and the disclosure argument are separate. A reported, reproduced, acknowledged code-execution flaw going seven months without a patch is a broken process regardless of how many people it endangers -- and the population it endangers is not small. Cloning and opening unfamiliar repositories is not an exotic activity in 2026; it is the core loop of evaluating a dependency, reviewing a contribution, or trying the tool somebody posted. And the entire pitch of an AI-native editor is that you point it at unfamiliar code and let it read.
That is the part that connects to the rest of the week. The tools we are handing to AI agents are becoming the attack surface, and they are being built at a speed that outruns the security process wrapped around them. Google is abandoning Android backports because its own AI finds bugs faster than humans can fix them. The Grok Build command-line tool was caught uploading whole repositories to cloud storage while promising the opposite. And Destructive Command Guard -- a hook that intercepts destructive shell commands before an agent can run them -- has 4,400 stars precisely because this class of failure is now routine enough to need a product.
There is a pattern in all three: the discovery and disclosure machinery is intact and working -- researchers found these things, wrote them up, filed them correctly -- and the remediation machinery is not keeping pace. Mindgard did everything right. The bug is still there.
The honest caveat: this is a one-sided account. Cursor has not published its side, and there may be a reason for the delay that looks better from inside than seven months of silence looks from outside. But the reasonable thing for a developer to do today does not depend on that. If you run Cursor on Windows, look at what is in the folder before you open it -- and treat the fix, whenever it lands, as the news.
Originally published on Ground Truth, where every claim is checked against the primary source.
Top comments (0)