Mindgard publicly disclosed on July 14, 2026 a vulnerability in the popular Cursor IDE that allows automatic arbitrary code execution upon opening a repository, without user interaction. The vulnerability was discovered on December 15, 2025 and reported to Cursor the same day: more than seven months later, no patch has been released and the vendor, valued at approximately $60 billion, classified the report as out of scope for its bug bounty.
- Cursor automatically executes a git.exe file placed in the root of a repository, without warning or user approval, exploiting path resolution logic that includes the workspace itself among the search locations for Git binaries.
- Mindgard's proof of concept used Windows Calculator renamed to git.exe, executed automatically upon opening the repository; Cursor repeatedly launched the binary during normal operation, not only at initial load.
- The vulnerability persisted in version 3.2.16 tested on April 30, 2026, after more than 197 versions released and more than 70 releases without response following HackerOne confirmation.
- Cursor triaged and fixed another Git-related report from a different researcher in version 2.5, demonstrating that the remediation process works selectively.
The Mechanism: Untrusted Search Path in an IDE with Millions of Users
The vulnerability lies in the logic Cursor uses to resolve Git binary paths. According to the technical description provided by Mindgard, the IDE searches for binaries in multiple locations; one of these is the workspace itself, meaning the directory of the opened repository. When an attacker places a malicious git.exe file in the repository root, Cursor executes it automatically without prompt or visual indication.
As Aaron Portnoy of Mindgard explained: "That is an untrusted-search-path vulnerability (CWE-426/427) in Cursor, not a malicious input the customer chose to trust". The distinction is relevant: this is not a user knowingly executing unverified code, but an automatic IDE behavior that bypasses developer control.
The technical proof is documented with Process Monitor logs showing the git.exe process creation by Cursor.exe. The PoC requires no elevated privileges or special configurations: simply opening the compromised repository triggers execution.
The Disclosure: 7 Months of Silence and an Out-of-Scope Response
The disclosure timeline was documented in detail by Mindgard. The initial report of December 15, 2025 was handled via HackerOne, which reproduced and confirmed the vulnerability. Then began a period of silence spanning more than 70 Cursor releases.
On July 13, 2026, shortly before publication, Cursor responded that it was "addressing this". Subsequently, it classified the report as out of scope for the bug bounty. A Cursor spokesperson stated: "After closely reviewing this, our team assessed the report and confirmed it is out of scope for our bug bounty program".
Cursor claimed that the Workspace Trust feature prevents execution, but the feature is disabled by default in standard installations. The source does not specify whether Workspace Trust enabled actually blocks this specific vulnerability: Portnoy expressed doubts, while Cursor asserts the protection is effective.
Proof of Selective Capability: The Fix in 3 Days for Another Researcher
An element that sharpens criticism of the case management is the comparison with another report. According to Mindgard's documentation, Cursor triaged and fixed a different Git-related vulnerability from another researcher, publishing the fix in version 2.5. The timing is significant: three days before Mindgard requested an update and received no response.
"Seven months after initial disclosure, we have no indication that users are being protected, that remediation is underway, or that affected organizations have been informed"
This chronological fact raises questions about the selection of reports that are actually acted upon. Portnoy stated he could fix the vulnerability "in about five minutes by reverse engineering the one line change they need to make", underscoring the technical simplicity of the required intervention.
Why It Matters
The dossier does not specify specific corrective measures released by Cursor. The source does not document in-the-wild exploitation of the vulnerability, nor does it confirm that the flaw exists on non-Windows platforms: Cursor defines it as "narrowly scoped, affects Windows only", but no independent verification is cited to confirm or refute this limitation.
No CVSS score has been assigned by any source in the dossier. No infrastructure overlaps emerge linking this vulnerability to other known incidents in the AI coding tools sector.
The brief does not specify whether Cursor has informed the more than 50,000 companies using the product, nor whether it has published security advisories. The cited measure does not document a communication path to enterprise users.
The potential impact remains concrete: with more than 7 million active users and more than 1 million daily users, the exposure base is wide. The attack mechanism is simple and the barrier to exploitation low: a public or shared repository with a modified git.exe file is sufficient.
Analysis: Coordinated Disclosure on Trial
The episode occurs at a moment of intense competition in the AI-assisted IDE market, where feature release velocity often overshadows security. Cursor, valued at approximately $60 billion, has demonstrated it possesses the channels and technical capacity to triage and fix Git-related reports. The choice not to do so in this specific case, combined with the out-of-scope classification, suggests a risk assessment that prioritizes other objectives.
For organizations using Cursor, the dossier's limit is clear: no vendor-documented solution exists. Workspace Trust, off by default, is not verified as an effective mitigation by independent sources. Mindgard's full disclosure publication appears as the only form of protection made available to users.
The case raises structural questions about the shared responsibility model for development tools: when a vendor classifies an automatic execution vulnerability as out of scope, the security burden shifts entirely to the end developer, often without tools to manage it.
Frequently Asked Questions
Is it necessary to interact with the repository to trigger execution?
No. According to the source, simply opening the repository in Cursor causes the git.exe file to execute automatically. The PoC with Windows Calculator was triggered simply by launching Cursor on that directory.
What is the difference between this vulnerability and the one reported by Knostic?
They are completely different mechanisms. The Knostic vulnerability, cited only as context from a separate source, concerns credential theft via MCP and browser hijacking. The Mindgard flaw is an untrusted search path leading to arbitrary code execution.
Has Cursor ever acknowledged this as a security vulnerability?
Cursor confirmed the report to HackerOne and initially indicated it was "addressing this". Subsequently, it classified the report as out of scope for the bug bounty. It has not released security advisories nor, as of the source dates, a patch.
Sources
- https://www.darkreading.com/application-security/cursor-ide-malicious-code-poisoned-repos
- https://www.darkreading.com/vulnerabilities-threats/cursor-issue-credential-stealing-attacks
- https://www.darkreading.com/application-security/ai-coding-tools-endpoint-security
- https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left
- https://www.darkreading.com/application-security/belgium-eid-authentication-citizen-accounts-rce
Information is based on cited sources and current as of publication.