A severe zero-click remote code execution (RCE) vulnerability has been identified in the Cursor AI-powered integrated development environment (IDE) for Windows, allowing attackers to execute arbitrary code on a user’s machine simply by having them open a malicious repository. The flaw, which has been known to Cursor for over seven months without a public patch or advisory, underscores a broader, unaddressed security blind spot within the burgeoning ecosystem of AI development tools. Cybersecurity firm Mindgard reported the vulnerability, which leverages a long-standing Windows behavior regarding executable search paths, leading to automatic execution of a malicious git.exe file placed within a project’s root directory.
The mechanism behind this critical vulnerability is deceptively simple and alarmingly effective. When a user opens a repository in Cursor on a Windows system, the IDE performs a routine check for a Git binary. Crucially, one of the locations Cursor scans for git.exe is the project’s root directory itself. If a file named git.exe is present in this location, Cursor automatically executes it without any user interaction, approval dialogs, or warnings. This means that an attacker can embed a malicious executable, disguised as git.exe, directly into a public or private repository. When a developer, unaware of the hidden danger, clones and subsequently opens this repository in Cursor, the malicious binary is immediately launched.
The implications of such an exploit are profound. The malicious git.exe binary runs with the full privileges of the logged-in user, gaining unfettered access to sensitive data and system resources. This includes the user’s source code, SSH keys, and potentially cloud tokens or other credentials configured within the development environment. Mindgard’s research indicates that the malicious binary continues to re-run for as long as the project remains open in Cursor, offering persistent control to the attacker. This is not a complex exploit involving prompt injection, sophisticated agent manipulation, or prior access to the target machine; the mere act of opening a folder containing the malicious file is sufficient to trigger arbitrary code execution.
Chronology of Disclosure and Vendor Inaction
Mindgard first identified and reported this critical flaw to Cursor on December 15, 2025. What followed was a protracted and concerning process of communication breakdown and perceived inaction from the vendor. Initially, Mindgard’s report encountered an automated system failure that prevented proper submission to Cursor’s private HackerOne bug bounty program. After a month, a substantive reply was received from Cursor’s CISO, who acknowledged the automation issue.
Following a resubmission, the report was initially closed the very next day by Cursor, categorized as "informative and out of scope," a decision that Mindgard vigorously challenged. Mindgard’s persistence, coupled with HackerOne’s ability to reproduce the vulnerability, led to the report being reopened. HackerOne confirmed delivery of the validated report on January 20, 2026. Despite this confirmation, Mindgard received no further updates from Cursor, despite sending multiple requests in February, March, and April 2026.
After seven months of silence and without any public patch or advisory from Cursor, Mindgard made the decision to proceed with full technical disclosure, publishing comprehensive details on Tuesday, July 15, 2026. This move, often referred to as the "nuclear option" in vulnerability disclosure, is typically reserved for situations where responsible disclosure processes have demonstrably failed to secure a fix or adequate communication from the vendor. Aaron Portnoy, the author of Mindgard’s report and a veteran in the cybersecurity disclosure space, having run the Zero Day Initiative and built the Pwn2Own contests, underscored the gravity of this decision.
The stark contrast between Cursor’s handling of Mindgard’s report and other disclosures during the same period further highlights the issue. Cursor’s public security advisories on GitHub show a functional disclosure process for other researchers. For instance, on February 13, 2026, Cursor published GHSA-8pcm-8jpx-hv8r, detailing a Git-hook sandbox escape (CVE-2026-26268) reported by Novee. This vulnerability was fixed in Cursor version 2.5 under a coordinated disclosure. Just three days later, on February 16, Mindgard sought an update on its own Git-related report, receiving no response. As of July 15, the day Mindgard’s full disclosure went live, Cursor’s official security advisories page listed no entry covering this specific issue, nor had a CVE been assigned. The current stable release of Cursor is 3.11, shipped on July 10, while Mindgard’s most recent dated confirmation of the bug’s presence was against Cursor 3.2.16 on April 30, 2026, with the write-up stating the bug persisted in the newest version tested, though not explicitly naming it.
The Pervasive Threat of Untrusted Search Paths in AI Tooling
Mindgard is not the first entity to identify this class of vulnerability, nor is Cursor the sole vendor implicated. In June 2026, cybersecurity firm Cymulate published its own research highlighting identical issues across several AI development tools running on Windows. The core problem lies in how these tools resolve helper executables: they utilize the operating system’s default search order, which, on Windows, prioritizes the current working directory (in this case, the project root) before searching trusted system paths defined in the %PATH% environment variable.
Cymulate’s findings revealed that GitHub Copilot CLI would execute a workspace-local git.exe at startup, even before displaying its folder-trust prompt. Similarly, Google’s Gemini CLI exhibited the same behavior when launched from a workspace containing a malicious binary. OpenAI’s Codex desktop application also automatically executed a rogue git.exe upon opening a folder, mirroring Cursor’s vulnerability.
As of Cymulate’s June 4, 2026, write-up, none of these vendors had released a fix for the reported vulnerabilities. Their responses varied but consistently downplayed the severity or feasibility of the attack:
- GitHub Copilot CLI: The report was triaged, a bounty was paid, but the severity was subsequently downgraded to low.
- Google Gemini CLI: Google acknowledged the finding as valid but did not release a patch.
- OpenAI Codex: The report was closed as "Not Applicable," with OpenAI reasoning that an attacker capable of replacing
git.exealready possesses system access. This argument fundamentally misunderstands the attack vector, which requires no prior system access but rather leverages the developer’s common practice of cloning and opening untrusted repositories. - Cursor CLI (Cymulate’s report): Similar to Mindgard’s initial experience, Cursor closed Cymulate’s report as "Informative" after eight days, stating that findings requiring a malicious binary "lack an attack vector."
This widespread dismissiveness from major vendors regarding a vulnerability that allows arbitrary code execution via a standard developer workflow is alarming. While Cymulate’s research did lead to one successful fix—AWS assigned CVE-2026-10591 for a different flaw in its Kiro tool (an agent file-write vulnerability that allowed a poisoned .vscode/tasks.json to auto-execute on folder open) and patched it in Kiro 0.11—none of the direct "binary planting" reports yielded immediate corrective action.
The class of vulnerability itself is not new. The concept of an untrusted search path being a weakness, and planting a binary in a location where the search order will find it first, has a precedent. For instance, CVE-2020-26233, affecting Git Credential Manager Core in 2020, involved a malicious git.exe at a repository’s top level being executed instead of the legitimate one during a recursive clone. This flaw was fixed in GCM 2.0.289. Blaze Information Security’s proof of concept for that vulnerability also utilized calc.exe renamed git.exe. Six years later, the identical trick continues to be effective, now targeting modern IDEs that automate the execution of such probes the moment a folder is opened.
Implications for Developers and Enterprise Security
The persistence of this vulnerability across multiple widely used development tools, particularly those leveraging AI, presents a significant and unmitigated risk to developers and the organizations they work for. The core problem is that a fundamental workflow for developers – cloning and exploring repositories, often from external or untrusted sources – is transformed into a direct attack vector. An attacker needs no prior foothold on a system; merely publishing a malicious repository is sufficient to compromise any developer who opens it with a vulnerable IDE.
The potential impact extends far beyond individual developer machines. Compromised developer workstations can serve as launchpads for broader attacks within an enterprise network, enabling lateral movement, access to source code repositories, intellectual property theft, or even supply chain attacks if malicious code is injected into projects. The fact that sensitive assets like SSH keys and cloud tokens are directly exposed makes this threat particularly potent.
The consistent vendor response, often downplaying the severity or misinterpreting the attack vector, raises serious questions about their understanding of real-world developer security practices. The argument that "an attacker who can replace git.exe already has system access" ignores the reality of how developers acquire binaries—by cloning repositories. This stance places the burden of defense squarely on the end-user and enterprise security teams, rather than addressing the root cause within the software itself.
Mitigation Strategies and Recommendations
Given the absence of official patches for Cursor and several other affected AI tools, the responsibility falls to individual developers and organizational IT security teams to implement workarounds.
For managed Windows fleets, Mindgard suggests proactive security measures:
- Application Control Policies: Implement AppLocker or Windows Defender Application Control (WDAC) deny rules. These rules should be configured to block executables by name and path under common workspace roots. For example, a rule like
%USERPROFILE%sourcerepos*filename.execould be used to preventgit.exeor other suspicious binaries from running from within cloned repositories. - Path Rules, Not Hashes: It is crucial to use path-based rules rather than hash-based ones, as attacker binaries will vary by hash, making hash-based blocking ineffective against new variants.
- Parent-Aware Enforcement: While Windows lacks a general built-in rule to block a child process only when a specific parent launches it, advanced Endpoint Detection and Response (EDR) solutions can often provide this level of granular control and monitoring. Organizations with EDR deployed should configure it to detect and prevent unusual process executions originating from IDEs within project directories.
For individual developers and smaller teams:
- Isolate Untrusted Repositories: Treat any repository cloned from an unknown or untrusted source as potentially hostile. Always open such repositories within a disposable virtual machine (VM) or a Windows Sandbox environment. This isolation prevents any malicious code from affecting the host operating system.
- Pre-Check Repositories: Before opening a cloned repository or extracted archive in an IDE, perform a manual inspection. Specifically, check the project root for unexpected executable files. Executables like
git.exe,npx.exe,node.exe, andwhere.exehave no legitimate business residing directly in a project’s root directory. If found, these should be viewed with extreme suspicion. - Principle of Least Privilege: Ensure that user accounts used for development have only the necessary permissions, minimizing the potential damage if a system is compromised.
Ultimately, the cybersecurity community’s consensus is clear: developers must now treat a cloned repository, particularly on Windows, as potentially executable content. This shift in mindset is critical to mitigate the risks posed by this class of vulnerabilities, which vendors have thus far been slow to address. The ongoing failure of multiple prominent AI tool developers to patch a known, easily exploitable vulnerability that can lead to arbitrary code execution underscores a concerning trend and places an undue burden on the user community to secure their development environments. The call for industry-wide adoption of secure executable search path practices and more responsive vulnerability disclosure processes remains urgent.
