Cursor Has an Unpatched Security Flaw: What to Know

TL;DR: A security firm has publicly disclosed a flaw in Cursor that it says the company left unpatched for seven months. On Windows, simply opening a booby-trapped project folder in Cursor can silently run an attacker’s code on your computer — no clicks, no warning. You’re fine if you only open your own projects. The practical rule until it’s fixed: don’t open code you got from a stranger inside Cursor.

What happened

On 14 July 2026, the security firm Mindgard published a “full disclosure” of a flaw in Cursor, the popular AI code editor. Several security outlets, including Dark Reading and SC Media, reported it.

Here’s the flaw in plain terms, based on their reports:

• On Windows, when Cursor opens a project it looks for a program called `git.exe` — and one of the places it looks is inside the project folder itself.
• So if a project folder contains a malicious `git.exe` in its root, Cursor runs it automatically when you open the project — with no prompt, warning, or approval.
• That gives the attacker the ability to run their own code on your computer, as you.
• The only thing the victim has to do is open the repository. Nothing else.

Mindgard says it verified this on Cursor version 3.2.16 and that the flaw was still present in the latest version they tested at disclosure time.

The timeline is the uncomfortable part. Mindgard reports it privately told Cursor on 15 December 2025; Cursor acknowledged it in January, then — according to Mindgard — went quiet for roughly seven months and 197+ releases without a fix. That’s why the firm went public: in its words, so users aren’t “left in the dark.” After the disclosure, a Cursor spokesperson told Dark Reading on 13 July: “I can confirm we are addressing this and will get back to Mindgard accordingly.” So it’s acknowledged — but, as of writing, not yet patched.

Why it matters if you don’t code

The scary-sounding version is “Cursor runs malware automatically.” The accurate version is narrower, and worth understanding so you can judge your own risk.

This only triggers when you open a project that someone else built to attack you. If you only ever open your own projects in Cursor, this specific flaw doesn’t touch you. The risk shows up the moment you open untrusted code — and beginners do that more than they realise:

• Downloading a “starter template” or example project from a random website, Discord, or YouTube description.
• Cloning a repo a stranger sent you “to take a look at”.
• Opening a project someone shared to get help debugging it.

On Windows, doing any of those in Cursor right now could — if that project was booby-trapped — run code on your machine without asking. That’s the practical takeaway: treat “open this repo in Cursor” like “run this .exe from a stranger.”

How to stay safe

1. Don’t open untrusted projects in Cursor — anything you didn’t create or don’t fully trust — until this is patched. This is the single most important step.
2. If you must open something untrusted, isolate it. On Windows, use Windows Sandbox or a throwaway virtual machine so the code can’t touch your real files.
3. Keep Cursor updated. Separately from this flaw, Cursor had other serious bugs (the “DuneSlide” prompt-injection issues) that were fixed in Cursor 3.0 — so being on the latest version protects you from those even though it doesn’t yet fix this one.
4. Don’t leave secrets lying around in project folders — passwords, API keys — so that if code ever does run, there’s less to steal.

Who should care (and who shouldn’t)

• You use Cursor on Windows and sometimes open shared/downloaded projects: act on this now — steps above.
• You only ever open your own projects: your immediate risk from this specific flaw is low. Stay tidy about what you open and update Cursor.
• You’re on Mac or Linux: this particular `git.exe` trick is a Windows behaviour. Good hygiene still applies, but the described attack targets Windows.
• You’re choosing your first tool: don’t drop Cursor over one bug — every tool has them. What’s worth weighing is how a company responds, and that’s the real story here.

Our take

The flaw itself is the kind of thing that gets fixed quickly when a vendor is paying attention. What’s harder to defend — and what turned a private bug report into a public warning — is seven months of silence. It’s the same pattern we flagged with the Grok CLI data-upload story this week: the incident matters less than how the company handles it. We still think Cursor is a genuinely strong tool, and we’d expect a fix soon. Until then, use it for your own work and keep strangers’ code at arm’s length.

Want a tool matched to how you actually work? Take the 60-second Vibe Coding Tool Finder quiz →

FAQ

Do I need to stop using Cursor?

No. The risk is specific: on Windows, opening a malicious project someone else made can run code on your PC. Working on your own projects is not the trigger. Until it’s patched, just don’t open untrusted code in Cursor — and update to the latest version.

Is my Mac affected?

The attack described here relies on a Windows behaviour (how Cursor finds `git.exe`). The reports focus on Windows. General caution about opening untrusted projects is still wise on any system.

I’ve seen other “Cursor vulnerability” headlines — are those the same thing?

Probably the “DuneSlide” flaws (CVE-2026-50548 / 50549), which are a different issue and were already patched in Cursor 3.0 (April 2026). This new one — the automatic `git.exe` execution — is separate and, as of writing, still unpatched. Updating Cursor fixes the former, not yet the latter.