Cursor Flaw Lets Malicious Cloned Repositories Trigger Windows Code Execution

# Cursor IDE Vulnerability Allows Arbitrary Code Execution Through Cloned Repositories

An unpatched critical security flaw in the Cursor code editor enables arbitrary code execution with zero user interaction the moment a developer opens a malicious repository. The vulnerability requires no exploits, no prompts, and no user awareness—simply cloning and opening a repository is sufficient to execute attacker-controlled binaries with full access to the developer's system, credentials, and source code.

Security firm Mindgard disclosed the issue publicly on July 15, 2026, more than seven months after reporting it to Cursor in December 2025. Despite the severity and timeline, Cursor has not released a patch, published a security advisory, or assigned a CVE identifier.

## The Threat: Instant Code Execution on Project Open

The flaw centers on how Cursor locates a Git binary when opening a new project. During initialization, Cursor searches multiple locations for git.exe—including the project root itself. If a file named git.exe exists in the workspace directory, Cursor executes it automatically with no confirmation, warning, or user interaction whatsoever.

The attack surface is immediate and dangerous:

Mindgard's proof-of-concept was elementary: rename Windows Calculator to git.exe, commit it to a repository root, and publish the repo. Upon cloning and opening in Cursor, Calculator windows spawn repeatedly on their own—demonstrating arbitrary execution.

## How the Exploit Works

Cursor uses a standard approach to locate system binaries: it checks several predefined locations when a project loads. According to process monitoring data included in Mindgard's write-up, Cursor.exe executes the repository-root binary with the command git rev-parse --show-toplevel—a standard Git command to identify the project's root directory.

The critical gap: This mimics Microsoft's documented VS Code binary-search behavior, but with a crucial difference. By searching the workspace itself before system paths, Cursor creates an implicit trust boundary—assuming that any file in a user's project directory is legitimate.

The mechanism is efficient; the security model is not. Developers download and open repositories constantly—from GitHub, GitLab, package repositories, and collaboration tools. A malicious binary sitting in project_root\git.exe appears indistinguishable from legitimate project files, yet it executes with full system privileges.

## Affected Versions and Timeline

Mindgard's testing confirmed the vulnerability in Cursor 3.2.16 (tested as of April 30, 2026). The current release, Cursor 3.11, shipped July 10, 2026—before public disclosure. The write-up notes the bug persists in the newest version tested, though Mindgard has not publicly named the exact current version confirmed vulnerable.

A critical detail: The Hacker News review of Cursor's 33 published security advisories found no entry addressing this issue as of July 15, 2026. No CVE has been assigned. When contacted, Cursor did not immediately confirm a fix or clarify which releases are safe.

## The Disclosure Gap: Seven Months Without Resolution

The vulnerability's journey through Cursor's security program raises questions about disclosure practices and incident response:

| Event | Date | Notes |

|-------|------|-------|

| Initial Report | December 15, 2025 | Mindgard submits via HackerOne |

| Automation Failure | January 2026 | Cursor's CISO explains security process failed to invite reporter to private program |

| Resubmitted & Closed | January 20, 2026 | Report marked "informative" and "out of scope" |

| Reopened | January 2026 | After pushback; HackerOne reproduces |

| Update Requests | February–April 2026 | Mindgard requests status; no response |

| Public Disclosure | July 15, 2026 | Mindgard publishes full technical details; no patch exists |

Cursor's security page commits to acknowledging vulnerability reports within five business days—a timeline evidently not met. While disclosure timelines vary across vendors, a seven-month gap without patch, advisory, or communication is unusual for a vulnerability of this severity.

## Risk Assessment: Who Is Exposed?

The attack works against any developer using Cursor on Windows, with the highest risk to:

The attack bypasses traditional defenses:

## Implications for Development Workflows

This vulnerability creates a silent risk in everyday development practices. The research, collaboration, and integration workflows that make modern development efficient now carry embedded execution risk.

Key exposures:

A single malicious repository could compromise dozens of developers across an organization if widely shared or forked.

## Mitigation and Workarounds

For Enterprise:

For Individual Developers:

General Practice:

## HackWire Analysis

This flaw represents a category of risk that modern development tools have inherited from their predecessors but failed to adequately defend against: implicit trust of local files. The assumption that a project directory contains only what developers deliberately placed there broke down the moment repositories became weaponizable attack surfaces.

What makes this particularly concerning is the seven-month disclosure timeline without resolution. Mindgard followed responsible disclosure to the letter—reporting, re-reporting, requesting updates—and received silence in return. Public disclosure occurred not because the vulnerability was finally patched, but because the reporter ran out of patience. This leaves developers unaware and unpatected.

The vendor's response is notable: Cursor initially classified the report as "out of scope," treating execution of binaries in a project directory as a user responsibility rather than an IDE design flaw. That framing is defensible from a certain angle—users do choose which repositories to clone. But it ignores the reality of how development actually works. Developers collaborate across dozens of repositories daily. The barrier to entry for an attacker is not special access or privilege; it is simply the ability to publish to GitHub, which is free.

The fix is straightforward: don't execute binaries from the project root. Search system paths only, or whitelist a specific subdirectory (like .tools/). Other editors have made this choice without significant friction.

Until Cursor patches this, developers using Windows should assume that opening any untrusted repository is equivalent to executing code from that source. The security model must change, not the workflow. — HackWire Editorial

## Recommendations for Developers and Organizations

1. Immediate: Audit recent Cursor usage and evaluate whether to restrict the tool until a patch is available

2. Short-term: Implement file-integrity monitoring and EDR rules that flag unexpected binary execution from development directories

3. Ongoing: Monitor Cursor's advisory page and subscribe to security updates; request CVE assignment from MITRE if Cursor does not provide one

4. Vendor communication: Contact Cursor directly demanding a patch timeline and security advisory; public pressure often accelerates vendor response

## The Broader Pattern

This incident is the latest in a series of supply-chain-focused attacks targeting developer tools and workflows. The common thread: ease of distribution. Code repositories, package managers, and build tools are distribution channels by design, and attackers have learned to weaponize them. IDEs and development environments are the final mile—the point where code from untrusted sources becomes executable.

Cursor's flaw is severe, but it is not unique. Other IDEs and development tools should audit their binary-search logic and project-root handling immediately. The bar for "trusted" has collapsed; the security model must evolve accordingly.

## Related Coverage