Cursor Has a 7-Month-Old Security Hole That Executes Malicious Code on Launch — And Nobody's Talking About It

Here's the mechanism. You clone a repository. You open it in Cursor on Windows. If that repo contains a file called `git.exe` in its root, Cursor executes it. No prompt. No warning. No click. Just instant, silent code execution with whatever privileges you're running under.

That's it. That's the whole vulnerability.

Mindgard security researchers found this on 15 December 2025. They reported it the same day. HackerOne confirmed it was valid and reproducible. Cursor shipped 197+ versions since. The bug is still there. And on 14 July 2026, Mindgard published the full disclosure. That's the nuclear option in vulnerability research, and they took it because coordinated disclosure had completely broken down.

If this sounds like a big deal, that's because it is. Cursor has 7 million users, a million paying, 50,000+ companies relying on it, and a $60 billion valuation courtesy of the pending SpaceX acquisition. Yet a bug that lets any random GitHub repo execute code on your machine just by being opened sat unfixed through seven months and nearly 200 releases. The silence from Cursor isn't just disappointing. At this scale, it's a statement about priorities.

Seven months of shipping, zero months of fixing

What makes this particular mess so hard to excuse is the simplicity of both the bug and the fix. Cursor's path resolution logic checks for Git binaries in several locations when it loads a project. One of those locations is the project workspace itself. Drop a malicious `git.exe` in the repo root, and Cursor runs it, repeatedly, on a cadence, as part of normal operation.

Mindgard's proof-of-concept used Windows Calculator renamed to `git.exe`. Open the project, Calculator pops up. Keep the project open, and Calculator keeps spawning. Replace Calculator with something actually harmful, and you've got a breach with the effort level of renaming a file.

The response timeline is where things go from bad to indefensible. Mindgard emailed Cursor's published security address in December. No confirmation. Followed up. Nothing. Eventually the CISO acknowledged an automation failure had eaten the original report, and Mindgard was invited to resubmit through Cursor's private HackerOne programme. HackerOne then closed it as "Informative" and out of scope. Mindgard pushed back. HackerOne reopened it, reproduced the bug, confirmed delivery to Cursor. And then: silence. No updates. No timeline. No acknowledgement. Direct outreach to Cursor leadership went unanswered.

Meanwhile, Cursor kept shipping. Features, announcements, growth. Seventy-plus versions in the period Mindgard was waiting for any sign of life. The valuation climbed. The SpaceX deal moved forward. The vulnerability stayed exactly where it was.

This isn't a story about a hard problem taking time to solve. It's a story about a company that stopped answering the phone.

2026 is becoming the year of "your AI tool is not your friend"

If this feels familiar, it's because we've been here before. Several times. In 2026 alone:

In May, researchers found over 5,000 vibe-coded applications leaking API keys, database credentials, and personal data because they were deployed without authentication. The tools that generated them never surfaced the risk.

In June, Claude Code was discovered to have embedded invisible watermarks (steganographic identifiers) in every prompt for three months without telling anyone, let alone the users whose outputs were being silently tagged.

Last week, Grok Build CLI was caught uploading entire home directories and full Git repositories to xAI's cloud storage, including `.git` history, without clear disclosure.

And now Cursor: automatic, silent code execution from any repo you open, ignored for seven months by a company about to be absorbed into the SpaceX empire.

There's a pattern here and it's not subtle. AI coding tools are being built and shipped at a velocity that makes security an afterthought, when it's a thought at all. The implicit bargain these tools offer is: "We'll handle the complexity, you just describe what you want." But the bargain only works if you also trust the tool not to execute random binaries, leak your source code, or watermark your outputs without consent. That trust is eroding fast.

What makes the Cursor case worse than the others is the attack surface. The Claude Code watermarking was a privacy violation, but it wasn't a remote code execution vector. The vibe-coded app leaks were user error magnified by tool defaults. The Grok CLI uploads were a data exfiltration concern. The Cursor bug is pure, classic arbitrary code execution. The kind of vulnerability the industry spent the 2000s learning to treat as critical. And Cursor treated it like a support ticket about font rendering.

What vibe coders and no-code builders should do

If you're a vibe coder (someone using AI to write software without deep engineering experience), this is your wake-up call. The tools you use have execution surfaces you may not understand and almost certainly aren't auditing. When Cursor auto-executes a binary from your project directory, there's no popup that says "Hey, this project just ran something." You won't know it happened.

The practical advice for Cursor users is straightforward but uncomfortable: don't open repos you haven't fully audited. On Windows, use AppLocker policies to block `git.exe` execution from workspace directories. On consumer machines, sandbox everything. But the real advice is simpler: recognise that AI coding tools are not sandboxed development environments. They have filesystem access, network access, process-spawning capability, and an increasingly complex stack of plugins, extensions, and agent behaviours. The surface area is enormous and mostly unexamined.

For teams and organisations, the question gets harder. Do you let developers run an IDE that blindly executes binaries from project directories? Do you accept that your AI coding tool's security posture depends on whether anyone at the company bothers to read their HackerOne queue? If the answer to either question makes you uncomfortable, you already know what you need to do.

This isn't the first Cursor security problem, either. In September 2025, Oasis Security published research showing Cursor ships with Workspace Trust disabled by default. That means a malicious `.vscode/tasks.json` with a `runOn: folderOpen` trigger also executes arbitrary code on project open. Different mechanism, same outcome. Same deafening silence. When a pattern repeats, it stops being an oversight and starts being a posture.

Structured no-code doesn't have this attack surface

This is where the security argument for structured no-code platforms actually lands, and it's not just marketing. Bubble, Webflow, Stacker — these platforms don't execute arbitrary binaries from your project. They don't run shell commands. They don't spawn child processes based on files in your workspace. There is no attack surface where renaming Calculator to `git.exe` in the right folder gets you code execution, because there is no `git.exe` to hijack and no path resolution to exploit.

That's not to say no-code platforms are immune to security issues. Every platform has bugs. But the category of vulnerability we're seeing in AI coding tools (arbitrary local code execution, silent data exfiltration, hidden watermarking) simply doesn't map onto platforms that run in a browser sandbox with a defined, server-side execution model. The attack surface is smaller by design, not by accident.

For vibe coders who've been riding the Cursor/Bolt/Replit wave, the security calculus is changing. Six months ago, the tradeoff looked like: "AI coding tools are faster, but you need to know what you're doing." Now it looks more like: "AI coding tools are faster, and they might execute code you didn't write, upload files you didn't choose, and ignore security reports for seven months while closing a $60 billion acquisition." The gap between "move fast" and "get breached" is narrowing, and it's narrowing at a pace most builders haven't clocked yet.

The takeaway

Mindgard did what security researchers are supposed to do when coordinated disclosure fails: they told the public so users could protect themselves. Cursor did what companies do when growth outpaces responsibility: they stopped answering.

If you use Cursor on Windows, mitigate now. AppLocker policies if you're on managed machines. Isolated VMs if you're on your own. Sandbox everything you clone. If you're responsible for a team using AI coding tools, ask yourself whether the security infrastructure you've built assumes good-faith vendor behaviour that you're not actually getting. And if you're choosing between AI coding tools and structured no-code for your next project, factor in the trust gap. The speed advantage of AI IDEs means nothing if you can't open a repo without wondering what just ran.