Open a project in Cursor on Windows, and if there's a file called git.exe sitting at the top level of that repository, Cursor will simply execute it — no prompts, no security warnings, nothing indicating the folder holds anything that's about to run.

Whatever that file is programmed to do, it does under your identity, with access to your codebase, SSH credentials, and cloud authentication tokens. And Cursor doesn't just run it once — it keeps executing that binary repeatedly for as long as the project remains open.

There's no need for prompt injection, no AI agent involved, no model making decisions, and no existing foothold on the target machine. Simply opening the folder is enough to trigger arbitrary code execution under the logged-in user's permissions.

The AI security company Mindgard flagged this issue to Cursor back on December 15, 2025, and released complete technical documentation this past Tuesday — seven months after the initial report. As of now, no patch exists, and Cursor has issued no public advisory acknowledging the problem.

The underlying issue is straightforward: when a project loads, Cursor checks multiple locations for a Git executable, and the workspace directory itself is one of those locations. Process monitoring data included in Mindgard's report shows Cursor.exe launching a binary from the repo root using the command git rev-parse --show-toplevel.

This lines up with the repository-root check that Microsoft documents for VS Code. The write-up doesn't clarify whether Cursor performs this search on its own or simply calls an unqualified "git" command and lets Windows' default search order determine what gets executed.

To prove the concept, Mindgard took the standard Windows Calculator app, renamed it git.exe, and placed it in the repository's root folder. From there, all it took was cloning and opening the project — the included screenshot shows Calculator windows popping up repeatedly on their own while the project remained open.

It might seem like getting a malicious file into someone's project folder would be difficult, but it isn't — cloning repositories from strangers is a routine part of software development, done constantly by both human developers and their AI agents. An attacker doesn't need any existing access to the victim's system beforehand. That's what makes this bug so effective: it turns a publicly-shared repository into a path toward code execution under the victim's own account.

One caveat: Mindgard's latest confirmed test was dated April 30, 2026, against Cursor version 3.2.16, while the current release, version 3.11, shipped July 10th. The report states the vulnerability persists in the newest version tested but doesn't specify what that version was.

Mitigation Steps

Since no official fix exists yet, everything below amounts to a workaround rather than a solution. For organizations managing Windows environments at scale, Mindgard recommends configuring AppLocker or Windows App Control rules that block execution by filename and path within workspace directories — for example, denying paths like %USERPROFILE%\source\repos*\filename.exe.

Since no official fix exists yet, everything below amounts to a workaround rather than a solution. For organizations managing Windows environments at scale, Mindgard recommends configuring AppLocker or Windows App Control rules that block execution by filename and path within workspace directories — for example, denying paths like %USERPROFILE%\source\repos*\filename.exe.

These should be path-based restrictions rather than hash-based ones, since attacker-controlled binaries will vary in hash value each time. The firm notes that Windows lacks a straightforward native mechanism to restrict a specific process based solely on which parent application launched it — achieving that level of control typically requires dedicated endpoint detection software. For individual users, the recommended approach is opening untrusted repositories inside a disposable virtual machine or Windows Sandbox environment.

This pairs well with guidance from Cymulate recommending that users inspect any cloned repository or extracted archive before opening it — files like git.exe, npx.exe, node.exe, or where.exe simply shouldn't be present in a project's root directory under normal circumstances. What happened after the report was submitted tells its own story.

Cursor's security page states that the company commits to acknowledging vulnerability submissions within five business days. Yet Mindgard's first meaningful response came a full month after their December submission — from Cursor's Chief Information Security Officer, who explained that an automated process had failed to add the firm to the company's private HackerOne bug bounty program.

Once resubmitted, the report was closed within a day, labeled as informational and outside the program's scope. It was only reopened after Mindgard objected, at which point HackerOne itself reproduced the issue and confirmed it had been received on January 20th. Following that, Mindgard sent follow-up requests in February, March, and April — receiving no response to any of them.

Comparing Cursor's public advisory history against Mindgard's timeline reveals that the disclosure system worked fine for other researchers even while Mindgard's report went unanswered. On February 13, 2026, Cursor published an advisory, GHSA-8pcm-8jpx-hv8r, covering a Git-hook sandbox escape vulnerability (CVE-2026-26268) that had been reported by a researcher named Novee and fixed in version 2.5. Just three days after that, on February 16th, Mindgard checked in again on their own similar Git-related finding — again, silence. Two additional advisories from Cursor came out on July 14th, the same day Mindgard's full disclosure went live.

Mindgard described full public disclosure as a last-resort measure, reserved for situations where every other avenue has been exhausted. Report author Aaron Portnoy brings relevant perspective here — he previously led the Zero Day Initiative and helped establish the earliest Pwn2Own hacking competitions.

A Pattern Across Multiple Vendors

Mindgard isn't alone in discovering this vulnerability class, nor the first to receive a similar runaround from Cursor. Back in June, the security firm Cymulate published research covering the same category of flaw across a range of AI development tools — on Windows, several of these tools rely on the operating system's default executable search order, which checks the current working directory before looking in trusted system locations.

GitHub's Copilot CLI tool executed a git.exe file from within the workspace at launch, even before displaying its folder-trust confirmation. Google's Gemini CLI exhibited identical behavior when started from within a workspace. OpenAI's Codex desktop application triggered the same issue simply upon opening a folder, mirroring Cursor's behavior.

As of Cymulate's June 4th report, none of these companies had released a fix. GitHub reviewed the submission, awarded a bounty, but then reclassified its severity as low. Google acknowledged the Gemini CLI issue as legitimate but hasn't shipped a patch. OpenAI closed its Codex report, categorizing it as not applicable, arguing that anyone capable of swapping out git.exe would already need system-level access — though that wasn't actually the scenario being described. Cursor, for its part, closed Cymulate's separate report about its CLI tool within eight days, deeming it purely informational on the basis that vulnerabilities requiring a malicious file don't constitute a genuine attack path.

That round of research did lead to one actual fix: AWS assigned CVE-2026-10591 to a related finding in its Kiro tool, credited Cymulate, and patched the issue in Kiro version 0.11. That was a distinct vulnerability, though — an AI agent file-writing flaw where a manipulated .vscode/tasks.json file would automatically execute upon opening a folder. None of the binary-planting reports elsewhere had resulted in a fix.

This entire category of vulnerability isn't new. The core weakness is an untrustworthy executable search path, exploited by planting a malicious file somewhere that search order will discover first. This exact issue — Windows checking the current directory before %PATH% — broke Git Credential Manager Core back in 2020, tracked as CVE-2020-26233: a fake git.exe placed at the top of a repository would run instead of the legitimate Git client during recursive cloning operations. That one was fixed in GCM version 2.0.289.

Notably, the proof-of-concept from Blaze Information Security for that older bug also used a renamed calc.exe file. Six years later, the identical trick now works against a modern IDE that runs the vulnerable check automatically the instant a folder is opened.

Four different vendors have now been shown proof that a binary planted in a workspace will self-execute on Windows the moment a developer opens a cloned repository. Two of them dismissed the issue entirely as not a real vulnerability. The other two accepted it as legitimate but, as of Cymulate's June report, still hadn't released any fix. That leaves the responsibility with individual defenders — and on Windows, the safest assumption is that a cloned repository should be treated as executable content, because functionally, that's exactly what it is.