The vulnerability nobody seems interested in fixing

Key Takeaways

After loading a project, Cursor attempts to find git binaries at various locations including the current workspace. By creating a repository with a planted malicious git.exe in the root, the IDE will execute it with no user interaction and no prompting of the user. This occurs repeatedly on a cadence.

Sometimes security research uncovers deeply technical vulnerabilities that require pages of explanation. This isn't one of those cases.

This bug is simple. A developer opens a repository in Cursor on Windows, and if that repository contains a malicious git.exe in the project root, Cursor will execute it automatically. There are no clicks, prompts, approval dialogs, or warnings. The result is arbitrary code execution.

Given that Cursor is one of the most widely adopted AI-assisted development environments (7 million+ active users, 1 million+ daily, 1 million+ paying, used by 50K+ companies), and its reported market price of $60 billion, it’s fair to assume that some level of respect for security practices exists, but this issue would indicate otherwise.

The vulnerability was first identified by Mindgard on December 15, 2025. We reported it the same day and multiple times since. More than six months and 197+ new versions later, the issue remains present in the latest tested version of Cursor.

The vulnerability is not theoretical and does not depend on a complex chain of exploitation, prompt injection, model manipulation, jailbreaks, memory corruption, or sophisticated attacker tradecraft. Exploitation simply requires a developer to open a project containing a git.exe binary in the repository at root.

‍

What Cursor Users Should Do Now

Enterprise/managed windows systems: As a temporary mitigation on managed Windows systems, administrators can use AppLocker or Windows App Control policies to deny execution of the affected executable name from developer workspace directories. Prefer path-based deny rules scoped to repo/workspace roots, such as %USERPROFILE%\source\repos\*\filename.exe, rather than hash-based rules, because attacker-supplied binaries can vary by hash. Windows does not provide a general built-in rule to block an arbitrary child executable only when launched by a specific parent process, so parent-aware enforcement generally requires EDR or a custom endpoint security product.

Consumer systems: Until the IDE is patched, open untrusted repositories only in an isolated VM, Windows Sandbox, or other disposable environment. Do not rely on file hash blocklists for this issue.

‍

A Strange Response to a Straightforward Problem

The most confusing part of this disclosure is the absence of a response from Cursor. Over the course of seven months, Mindgard repeatedly attempted to engage through every available channel. Initial disclosure was sent directly to Cursor's security reporting e-mail address, as specified in the company's published security.txt file. Follow-ups were sent when no confirmation was received. Public outreach was made in an attempt to identify an appropriate security contact.

Eventually, Cursor's CISO responded and acknowledged that an internal automation failure had prevented the expected HackerOne workflow from taking place. We were invited into the private bug bounty program and resubmitted the report.

The report was initially closed as Informative and out of scope. After we challenged that determination, HackerOne reopened the report, reproduced the issue, and confirmed that the details had been delivered to Cursor. And then everything stopped. Requests for updates went unanswered, additional follow-ups received no response, escalation through HackerOne produced no meaningful engagement, and direct outreach to Cursor leadership yielded the same result: no response.

Month after month has passed without evidence that remediation had begun, that engineering teams were actively investigating the issue, or that affected users would be informed as to the risk. Meanwhile, Cursor continued shipping releases. More than 70 versions came and went as features shipped, announcements continued, and the platform evolved. But the vulnerability remained present and repeated requests for a status update yielded no meaningful response.

At some point the conversation shifts from vulnerability disclosure to a more uncomfortable question: What exactly is the security process for?

‍

The Bug

The technical issue itself is remarkably straightforward. When loading a project, Cursor attempts to locate Git binaries across multiple locations. One of those locations includes the workspace itself.

If an attacker planted a malicious git.exe in the repository root, Cursor will execute it automatically as part of its path resolution logic without warning, approval, or even an indication that executable content from the repository is about to run.

To demonstrate the issue safely, Mindgard used a harmless proof-of-concept: the Windows Calculator application, renamed to git.exe, placed in the root of the repository. Simply launching Cursor against that repository was enough to execute it.

The screenshot below shows the result. The multiple Calculator windows were not opened manually by the researcher. Cursor continued to re-execute the renamed binary while the project was left open, causing more instances to appear over time. In other words, this was not a one-time launch event or a user-triggered action. Cursor repeatedly invoked executable content from inside the workspace during normal operation.

‍

A harmless proof-of-concept using Windows Calculator renamed to git.exe. Cursor repeatedly executed the binary from the repository root after the project was opened.

‍

In a real attack scenario, Calculator would simply be replaced with attacker-controlled code.

The result is arbitrary code execution under the privileges of the current user as demonstrated in the following Sysinternals process monitor logs (last verified on April 30, 2026 against Cursor version 3.2.16 on Windows.)

‍

4:25:12.6209706 PM	Cursor.exe	54880	Process Create	c:\Users\aport\Documents\Audits\cursor\test_repos\git_exec0001\git.exe	SUCCESS	PID: 48972, Command line: git rev-parse --show-toplevel	"C:\Users\aport\AppData\Local\Programs\cursor\Cursor.exe" 	C:\Users\aport\AppData\Local\Programs\cursor\Cursor.exe 

‍

The vulnerability is almost boring in its simplicity, and that may be the most concerning part. During normal operation, Cursor executes an attacker-controlled binary from a repository with no user interaction required. The fact that such a straightforward issue can persist for months without remediation should concern every individual and organization currently deploying Cursor.

‍

Why This Disclosure Is Different

Most coordinated disclosures follow a familiar pattern:

1. A vulnerability is reported.
2. A dialogue begins.
3. Severity is discussed.
4. Engineering teams investigate.
5. Fixes are developed.
6. Users are protected.
7. Public disclosure follows.

That process works because all parties share a common objective: reducing risk.

Unfortunately, this case never reached the stage of risk reduction. After seven  months and no vendor engagement, it’s time to question if remediation for such a simple, high impact vulnerability will ever occur.

Security researchers understand that remediation takes time, particularly inside large and rapidly evolving software platforms. Patience becomes difficult to justify, however, when months pass without communication, updates, or visible progress. Users deserve basic protections against basic threats, and when a vendor stops communicating while continuing to distribute affected software, researchers eventually face an uncomfortable decision:

1. Remain silent and allow users to operate under a false assumption of safety.
2. Or, disclose the issue publicly so organizations can make informed risk decisions.

We believe users deserve the information. Full disclosure is the nuclear option of vulnerability disclosure, reserved for situations where every other path has failed. It exists for a reason: when vendors stop communicating, users should not be left in the dark.

‍

What Happens When Innovation Stops Listening?

The most obvious question is also the simplest: Why hasn't this been fixed?

The vulnerability is neither subtle nor difficult to reproduce, has a straightforward execution path and critical impact. The lackluster response from Cursor leads to much broader questions:

• Are modern bug bounty programs becoming overloaded?
• Are bug bounty programs overloaded due to increasingly competent models, such as Mythos?
• Is Cursor preoccupied with their SpaceX acquisition and de-prioritizing user safety?
• Is user safety of any concern when billions of dollars are at stake?

The security industry has spent years encouraging researchers to use coordinated disclosure channels. Those channels depend on responsive triage processes and vendors having the capacity to evaluate and act on incoming reports. However as AI products proliferate, the volume of security findings is increasing dramatically. Many of those findings are novel and do not fit neatly into traditional vulnerability categories. At the same time, the triage processes we have relied on for nearly two decades are rapidly failing as the core assumptions they are built upon crumble under the emerging world of AI.

If disclosure pipelines are becoming overwhelmed, the industry should say so. Researchers, customers, and users deserve transparency.

Sadly, that may not be the case as uncomfortable questions of priority grow. Like many others, Cursor has been at the center of enormous growth, investment, and industry attention. The company is expanding rapidly, yet from the outside it is difficult to reconcile that growth with the absence of visible progress on a straightforward arbitrary code execution vulnerability.

Rapid growth introduces a responsibility to address security failures while also requiring the treatment of users as valuable customers, not buying experiments. They are trusting production software with access to source code, credentials, proprietary intellectual property, and increasingly, autonomous capabilities.

Trust requires accountability, and accountability requires communication. When users, researchers, and disclosure platforms spend months seeking basic status updates without success, that accountability becomes difficult to see or believe in.

‍

The Bigger Problem

This disclosure goes beyond a single executable named git.exe to the place of trust in software. AI companies routinely ask users to grant unprecedented levels of access to code, repositories, terminals, secrets, and workflows that increasingly blur the line between suggestion and action.

The industry narrative is that these systems deserve trust because they increase productivity, but history has taught us time and again that trust should not be granted because something is useful. It should be earned through behavior. That behavior is reflected in how a company responds to security reports, communicates with affected users, and prioritizes remediation.

When straightforward vulnerabilities remain unresolved for months without meaningful communication, users are forced to reevaluate assumptions about that trust.

‍

Why We Are Going Full Disclosure

Like many security research teams, Mindgard prefers coordinated disclosure. The goal is always security first, publicity second.

But coordinated disclosure only works when there is coordination. 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. And at this point, withholding information no longer serves users, it serves silence.

For that reason, Mindgard is releasing full details of this vulnerability. Organizations using Cursor deserve the opportunity to evaluate their exposure, implement compensating controls, and make informed decisions about their security posture.

User safety must come first, even when disclosure becomes uncomfortable.

Especially when disclosure becomes uncomfortable.

‍

Timeline