安全行业多年来一直鼓励研究人员使用协调披露渠道。这些渠道依赖于响应迅速的分类处理流程以及供应商有能力评估和处理收到的报告。然而，随着 AI 产品的普及，安全发现的数量正在急剧增加。其中许多发现是新的，不能整齐地归入传统的漏洞类别。同时，我们近二十年来依赖的分类处理流程正在迅速失效，因为它们构建的核心假设在新兴的 AI 世界中正在崩溃。
Mindgard 是领先的 AI 安全解决方案提供商，帮助企业发现、评估并防御其 AI 系统。Mindgard 从兰开斯特大学十多年 AI 安全研究中独立出来，总部设在波士顿和伦敦，将 AI 红队：https://mindgard.ai/blog/what-is-ai-red-teaming 与进攻性安全专业知识及 AI 研究结合起来，以在攻击者之前识别 AI 模型、代理和应用中的可利用漏洞。
Discover shadow AI and agents. Reveal the AI attack surface
Continuously test AI agents & systems against evolving attacks
Find and fix AI security and safety vulnerabilities
Identify and respond to attacks in real time
The vulnerability nobody seems interested in fixing
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：https://cursor.com/ 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：https://www.forbes.com/sites/richardnieva/2026/06/08/cursor-4-billion-annualized-revenue/, 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.
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.
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：https://cursor.com/.well-known/security.txt. Follow-ups were sent when no confirmation was received. Public outreach：https://www.linkedin.com/posts/aaronportnoy_can-anyone-put-me-in-touch-with-a-security-share-7416965166954868736-agkL/ 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 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.
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：https://learn.microsoft.com/en-us/sysinternals/downloads/procmon (last verified on April 30, 2026 against Cursor version 3.2.16 on Windows.)
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.
Most coordinated disclosures follow a familiar pattern:
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:
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.
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:
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.
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.
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.
See how Mindgard exposes and fixes exploitable AI risk across your AI agents and systems.
Mindgard, the leading provider of AI security solutions, helps enterprises discover, assess, and defend their AI systems. Spun out from over a decade of AI security research at Lancaster University and headquartered in Boston and London, Mindgard combines AI red teaming：https://mindgard.ai/blog/what-is-ai-red-teaming with offensive security expertise and AI research to identify exploitable vulnerabilities in AI models, agents, and applications before attackers do.
扫码直达文章详情