Malicious Git Repositories Can Trigger Windows Code Execution via Cursor Bug

A newly disclosed security flaw in the Cursor AI coding environment could allow attackers to execute arbitrary code on Windows systems simply by convincing a developer to open a malicious repository. The vulnerability requires no user approval, warning prompts, or interaction beyond opening the affected project folder.

According to security researchers at AI security firm Mindgard, Cursor automatically executes a file named git.exe if it is present in the root directory of a repository. Once the project is opened, the executable runs under the privileges of the logged-in user, inheriting access to source code, SSH keys, cloud credentials, and other sensitive resources. Even more concerning, Cursor reportedly continues to execute the file repeatedly while the repository remains open.

Unlike many modern attacks that rely on prompt injection, AI manipulation, or social engineering, this issue is remarkably simple. The entire attack chain is triggered by opening a cloned repository containing a malicious executable disguised as git.exe, resulting in immediate code execution on the victim's machine.

Vulnerability Remains Unpatched

Mindgard initially reported the issue to Cursor on December 15, 2025, and publicly disclosed full technical details seven months later after receiving no effective resolution. At the time of disclosure, no security advisory, software update, or official fix had been released by Cursor.

The flaw stems from the way Cursor searches for Git binaries when loading projects. Researchers found that one of the locations Cursor checks is the repository's own root directory. During startup, Cursor invokes Git-related commands, such as:

git rev-parse --show-toplevel

If a malicious executable named git.exe exists in the project folder, Cursor may launch it instead of the legitimate Git binary.

To demonstrate the issue, Mindgard created a proof-of-concept attack using Windows Calculator renamed to git.exe and placed it in a repository's root directory. Once the repository was cloned and opened in Cursor, Calculator launched automatically and repeatedly without any user action.

Why the Attack Is Dangerous

The attack requires no prior compromise of the victim's system. Developers routinely clone repositories from GitHub, GitLab, and other sources as part of their daily workflow. An attacker simply needs to publish a repository containing a malicious executable and persuade a target to open it in Cursor.

This effectively bridges the gap between an untrusted repository on the internet and arbitrary code execution on a developer's workstation.

Because the malicious process runs under the victim's account, it can potentially:

• Access source code repositories
• Steal SSH keys and API tokens
• Capture cloud credentials
• Install persistent malware
• Move laterally within enterprise environments

Limited Visibility Into Current Impact

Mindgard confirmed the vulnerability as recently as April 30, 2026, while testing Cursor version 3.2.16. Although researchers stated that the issue remained present in newer releases they evaluated, they did not publicly identify the exact version tested. Cursor's current release at the time of disclosure was version 3.11.

A review of Cursor's published security advisories revealed no mention of the vulnerability, and no CVE identifier has been assigned.

Recommended Mitigations

Since no official patch is currently available, organizations must rely on compensating controls and security best practices.

For managed Windows environments, researchers recommend implementing:

• AppLocker policies
• Windows Defender Application Control (WDAC) rules
• Endpoint Detection and Response (EDR) protections

These controls should prevent execution of suspicious binaries located within repository directories.

Developers are also encouraged to:

• Inspect repositories before opening them
• Avoid opening untrusted projects directly on production workstations
• Use Windows Sandbox or isolated virtual machines for testing unfamiliar code
• Watch for unexpected executables such as:
  • git.exe
  • node.exe
  • npx.exe
  • where.exe

Any of these files appearing in a repository root should be treated as suspicious.

Disclosure Process Raises Concerns

Mindgard's disclosure timeline has raised additional questions regarding vulnerability handling and response procedures.

According to the researchers, their initial report encountered delays due to issues with Cursor's vulnerability intake process. After being resubmitted, the report was reportedly categorized as informational and initially considered outside the scope of the company's bug bounty program.

Although HackerOne later reproduced and validated the findings, Mindgard states that repeated requests for updates received little or no response.

Eventually, the company opted for full public disclosure, describing it as a last resort after other remediation avenues appeared unsuccessful.

Not an Isolated Issue

The Cursor vulnerability is part of a broader security issue affecting several AI development platforms and coding assistants.

Earlier research by Cymulate identified similar behaviors in:

• GitHub Copilot CLI
• Google Gemini CLI
• OpenAI Codex Desktop
• Cursor CLI

In each case, Windows search path behavior allowed workspace-located executables to be prioritized over trusted system binaries.

While vendors responded differently to disclosure reports, security researchers noted that several organizations either considered the risk low severity or disputed whether the behavior constituted a security vulnerability.

A Long-Standing Security Weakness

The underlying issue is not new. It stems from the classic Untrusted Search Path vulnerability category, where applications inadvertently execute attacker-controlled binaries located in user-controlled directories.

A similar flaw affected Git Credential Manager Core in 2020 (CVE-2020-26233), where a malicious git.exe placed inside a repository could be executed instead of the legitimate Git binary. That issue was ultimately patched.

The Cursor finding demonstrates that the same attack technique remains relevant years later, particularly as developer tools become increasingly automated.

Conclusion

The Cursor vulnerability highlights a critical security concern for software developers and organizations adopting AI-powered coding tools. By simply opening a cloned repository containing a malicious git.exe, users may unknowingly execute attacker-controlled code with their own privileges.

Until a patch becomes available, security teams should assume that cloned repositories can contain executable threats, implement strict application control policies, and encourage developers to validate project contents before opening them. In today's software supply chain environment, an untrusted repository should be treated as potentially active code, not merely a collection of files.