Cursor 0day: Why a 7-Month-Old Vulnerability Is Still Unpatched
TL;DR
Security researchers disclosed a Cursor vulnerability that auto-executes malicious git.exe files from repos - after waiting 7 months with no fix.
Open a Git repository in Cursor on Windows. If that repo contains a malicious git.exe in the root directory, Cursor will execute it automatically. No clicks, no prompts, no warnings.
That's the vulnerability Mindgard disclosed on July 14, 2026 - after seven months of silence from Cursor and over 70 new releases shipped without a fix.
The Vulnerability#
The issue is in Cursor's Git binary discovery process. When loading a project, Cursor searches multiple file system locations for Git executables - including the workspace itself. If an attacker plants a git.exe in the repository root, Cursor treats it as a legitimate system binary and executes it.
Mindgard's proof-of-concept was straightforward: rename Windows Calculator to git.exe, place it in a repository root, open the project in Cursor. Process monitor logs showed Cursor.exe spawning the malicious executable with commands like git rev-parse --show-toplevel.
The impact is arbitrary code execution under the current user's privileges. The attack requires only that a developer clone or open an untrusted repository - a common action when reviewing open-source code, interviewing candidates, or working with external contributors.
The Timeline#
Mindgard's disclosure timeline shows a pattern of vendor non-engagement:
- December 15, 2025: Vulnerability discovered and reported to Cursor via HackerOne
- January 15, 2026: Cursor's CISO manually added researchers to bug bounty after acknowledging an "automation failure"
- January 16, 2026: Report initially dismissed as out-of-scope, then reopened after challenge
- February-June 2026: Multiple update requests went unanswered
- July 14, 2026: Full public disclosure after no evidence of remediation
As the researchers note: "Month after month has passed without evidence that remediation had begun...Meanwhile, Cursor continued shipping releases. More than 70 versions came and went."
What HN Is Saying#
The Hacker News discussion is split between those who see this as a critical flaw and those who argue the threat model is misunderstood.
On the feature's existence: One commenter speculated, "I'm struggling to understand the process that went into this 'feature' existing. It seems the most likely candidate is a developer's git started malfunctioning and an agent 'fixed' it by dropping a git.exe in the repo."
Skepticism about severity: Several commenters pointed out that you need to already have a malicious payload on your system: "You need to have an already malicious payload on your pc to make this exploit work (via clone/download/magic). I can understand the severity of the exploit but at the same time I'd hope to not have to run into this situation for it to happen in the first place."
Comparison to existing threats: A pragmatic take: "Frankly, if you git clone a compromised repository, I'm not sure that a vulnerability of the class 'compromised code in that repository will be executed' is all that major a concern. There are plenty of IDEs that will go autonomously run npm installs (with post-install scripts) for you when they detect a package.json."
On the trust dialog: Cursor does show a "do you trust this repository?" dialog when opening projects. One commenter asked the key question: "Does the git lookup run before the trust check, or ignore it?"
On Cursor's response: The consensus was that the vendor's silence is more alarming than the bug itself: "It's pretty weird for cursor to run arbitrary exe file without prompting, and alarming that the researchers did not get a proper response for months."
The Broader Context#
This disclosure arrives alongside other Cursor security findings in 2026:
- CVE-2026-26268: A high-severity (CVSS 8.1) arbitrary code execution vulnerability via Git hooks
- CVE-2026-50548 and CVE-2026-50549: The "DuneSlide" flaws rated 9.8/10 by Cato AI Labs, enabling prompt injection to escape the sandbox and run OS commands
The pattern suggests that Cursor's rapid feature development may have outpaced security review. With 7+ million active users, 1 million daily users, and 50,000+ companies relying on the tool, the attack surface is substantial.
Practical Mitigations#
Until Cursor patches the vulnerability:
For enterprise users: Deploy AppLocker or Windows Defender Application Control policies to block executable files from running within workspace directories. This prevents the attack regardless of the specific binary name.
For individual developers: Open untrusted repositories only in isolated environments - Windows Sandbox, a VM, or a container. This adds friction but eliminates the risk.
For everyone: Be selective about what repositories you clone. The attack requires a malicious git.exe to be present, which means either a compromised upstream or a deliberately malicious repository.
The Disclosure Debate#
Mindgard's decision to publish after seven months follows standard responsible disclosure guidelines, which typically give vendors 90 days before going public. The extended timeline here appears to reflect multiple attempts at contact and a genuine hope for resolution.
But as one HN commenter noted: "it truly feels like nobody here cares about helping as much as they care about PR." The tension between security research and commercial interests is as old as the industry itself.
What's less debatable is the outcome: developers are now aware of a risk they couldn't assess before. Whether that's worth the potential for exploitation is the eternal tradeoff of public disclosure.
FAQ#
Is this vulnerability specific to Windows?#
Yes. The git.exe binary discovery issue is Windows-specific. Mac and Linux users are not affected by this particular vulnerability.
Does the "trust this repository" dialog protect me?#
The disclosure doesn't clarify whether the Git lookup runs before or after the trust check. Until confirmed, assume it does not provide protection.
What version of Cursor is affected?#
According to the disclosure, the vulnerability was present in the latest tested version as of July 2026, and remained unfixed across 70+ releases since December 2025.
Are other code editors vulnerable?#
The specific path resolution logic is Cursor-specific. However, similar issues could exist in any editor that searches for binaries in user-controllable locations. VS Code, for example, has had its own security disclosures around extension trust and terminal execution.
Continue Reading#
- Android May Soon Restrict On-Device ADB - What Developers Need to Know
- Clawk: Disposable Linux VMs for Coding Agents Without Cloud Bills
- Dan Luu's Agentic Coding Notes Point to the Real Bottleneck
Sources#
Get the next deep dive like this in your inbox
One email a week on News and the rest of the AI dev stack. Free.
Read next on AI coding tools
Ruff v0.16.0: 413 Default Rules, Markdown Formatting, and What Zero-Config Linting Means for Python
Ruff v0.16.0 ships 413 default rules (up from 59), Markdown code-block formatting, and a new ruff: ignore system. Here is what changed, what HN is saying, and why zero-config linting matters more with AI coding agents.
5 min readAndroid May Soon Restrict On-Device ADB - What Developers Need to Know
A Google ADB maintainer proposed restricting on-device ADB connections to loopback, which would break Shizuku, libadb-android, Termux workflows, and an entire ecosystem of open-source power-user apps.
7 min readWhat xAI's Grok Build CLI Actually Sends Home: A Wire-Level Analysis
A security researcher intercepted Grok Build's network traffic and found it uploads entire repositories - including .env files with secrets - to xAI servers. Here's what the data shows.
6 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.
