Which Cursor versions are affected by the git.exe 0day?

Mindgard reports the Cursor for Windows git.exe auto-execution flaw is present in every version tested between the initial December 15 2025 report and Cursor 3.2.16, verified as recently as April 30 2026. Cursor has not published a patch as of the July 14 2026 disclosure; Mindgard says the issue persisted across 197+ builds.

How does the Cursor git.exe exploit work?

Cursor searches several locations for the Git binary when it needs to run commands like status, diff, or fetch. The workspace directory sits earlier in that resolution order than the system PATH, so an attacker-supplied git.exe planted in the repo root is picked up and launched as a normal child process, inheriting the user's privileges and network access.

Has Cursor patched the git.exe vulnerability yet?

No patch was public at the time of Mindgard's July 14 2026 disclosure. A Cursor spokesperson told Dark Reading on July 13 that the company was addressing the issue and would follow up with Mindgard, but no fixed version, CVE, or advisory had been published on cursor.com when the writeup went live.

How can Windows developers protect themselves right now?

Mindgard recommends enterprise fleets deny execution from developer workspace paths using AppLocker or Windows App Control, so any git.exe planted in a repo cannot run. Individual developers should only open untrusted repositories inside Windows Sandbox or a disposable VM until Cursor ships a fix that no longer searches the workspace directory for git.

Is this the same as the DuneSlide Cursor bug from earlier this month?

No — Mindgard's Cursor 0day is a distinct issue from DuneSlide (CVE-2026-50548/9), which Cato Networks disclosed in early July and was patched in Cursor 3.0. DuneSlide required a prompt-injection payload to escape the AI sandbox; the git.exe flaw requires no LLM interaction at all, just opening a poisoned repo.

Mindgard · 2026-07-14 · major

Cursor 0day disclosed — Windows RCE via auto-executed git.exe in a repo

Mindgard publishes full disclosure of a Cursor for Windows flaw: opening a repository whose root contains a malicious git.exe causes Cursor to auto-run the binary with no prompt, giving an attacker arbitrary code execution as the user.

Mindgard 'Cursor 0day' disclosure hero image

Mindgard drops a Cursor 0day: opening a Windows repo whose root contains a malicious git.exe silently launches it under the developer's account.

Quick facts

Reporter	Aaron Portnoy (Mindgard)
Affected product	Cursor for Windows, through 3.2.16
Trigger	Opening a repo whose root contains git.exe
Impact	Arbitrary code execution as the current user
Disclosure gap	~7 months (Dec 15 2025 → Jul 14 2026)
CVE	Not yet assigned
Mitigation	AppLocker / Windows App Control, or open untrusted repos in a sandbox VM

What is it?

Cursor for Windows automatically executes any git.exe file placed in the root of a repository as soon as the user opens that project, with no prompt, no warning, and no user click required. Any attacker who can get a developer to open a poisoned repository — a clone, a downloaded ZIP, a shared workspace — gets arbitrary code execution under that developer's account.

How does it work?

The bug lives in Cursor's process-resolution logic for helper binaries. When Cursor needs to run git for common actions like reading branch state or computing a diff, it looks in several locations before falling back to the system PATH — and the workspace directory is one of those earlier locations. A git.exe placed there is picked up first and launched as a normal child process, so the attacker's binary inherits the user's privileges, tokens, and network access. Mindgard verified the behavior across 197+ Cursor builds up through version 3.2.16.

Why does it matter?

Cloning an untrusted repository into Cursor is now an unsafe act on Windows, and the same class of flaw likely affects other AI coding tools that spawn local helpers. Mindgard's timeline is the second story here: the vulnerability was reported on December 15 2025, sat unfixed through the HackerOne workflow for seven months, and only got a public acknowledgement — a spokesperson statement to Dark Reading on July 13 — hours before the writeup went live. Enterprises that let developers open arbitrary repos in Cursor should ship a workspace-execution policy today.

Who is it for?

Windows developers using Cursor, and the security teams responsible for their workstations.

Frequently asked questions

Which Cursor versions are affected by the git.exe 0day?: Mindgard reports the Cursor for Windows git.exe auto-execution flaw is present in every version tested between the initial December 15 2025 report and Cursor 3.2.16, verified as recently as April 30 2026. Cursor has not published a patch as of the July 14 2026 disclosure; Mindgard says the issue persisted across 197+ builds.
How does the Cursor git.exe exploit work?: Cursor searches several locations for the Git binary when it needs to run commands like status, diff, or fetch. The workspace directory sits earlier in that resolution order than the system PATH, so an attacker-supplied git.exe planted in the repo root is picked up and launched as a normal child process, inheriting the user's privileges and network access.
Has Cursor patched the git.exe vulnerability yet?: No patch was public at the time of Mindgard's July 14 2026 disclosure. A Cursor spokesperson told Dark Reading on July 13 that the company was addressing the issue and would follow up with Mindgard, but no fixed version, CVE, or advisory had been published on cursor.com when the writeup went live.
How can Windows developers protect themselves right now?: Mindgard recommends enterprise fleets deny execution from developer workspace paths using AppLocker or Windows App Control, so any git.exe planted in a repo cannot run. Individual developers should only open untrusted repositories inside Windows Sandbox or a disposable VM until Cursor ships a fix that no longer searches the workspace directory for git.
Is this the same as the DuneSlide Cursor bug from earlier this month?: No — Mindgard's Cursor 0day is a distinct issue from DuneSlide (CVE-2026-50548/9), which Cato Networks disclosed in early July and was patched in Cursor 3.0. DuneSlide required a prompt-injection payload to escape the AI sandbox; the git.exe flaw requires no LLM interaction at all, just opening a poisoned repo.

Try it

Enterprise: AppLocker / Windows App Control policy denying execution from workspace paths. Individual: only open untrusted repos inside Windows Sandbox or a disposable VM.