Cursor 零日漏洞：当全面披露成为唯一剩下的保护手段
Aaron Portnoy
2026年7月14日
更新于：
2026年6月17日
一个似乎无人愿意修复的漏洞
核心要点
加载项目后，Cursor 会尝试在包括当前工作区在内的多个位置查找 git 二进制文件。通过在仓库根目录中创建一个包含植入的恶意 git.exe 的仓库，IDE 将在无需用户交互且无任何提示的情况下执行该文件。这种情况会按一定频率反复发生。
有时，安全研究会发现需要长篇解释的、技术性极强的漏洞。但这次并非如此。
这个漏洞很简单。开发者在 Windows 系统上使用 Cursor 打开一个仓库，如果该仓库的项目根目录中包含一个恶意的 git.exe，Cursor 会自动执行它。无需点击、无需提示、无需批准对话框，也没有任何警告。结果是任意代码执行。
鉴于 Cursor 是应用最广泛的 AI 辅助开发环境之一（拥有超过 700 万活跃用户、超过 100 万日活用户、超过 100 万付费用户，并被超过 5 万家公司使用），且其报道的市场估值高达 600 亿美元，人们有理由认为它具备一定水平的安全实践尊重，但这个漏洞表明情况恰恰相反。
该漏洞由 Mindgard 于 2025 年 12 月 15 日首次发现。我们当天就报告了该问题，此后又多次报告。六个多月过去了，在经历了 197 多个新版本之后，该问题在最新测试版本的 Cursor 中仍然存在。
该漏洞并非理论上的，也不依赖于复杂的利用链、提示词注入、模型操纵、越狱、内存损坏或高级攻击者技术。利用该漏洞只需开发者打开一个在其仓库根目录中包含 git.exe 二进制文件的项目。
Cursor 用户现在应该做什么
企业/托管 Windows 系统：作为托管 Windows 系统上的临时缓解措施，管理员可以使用 AppLocker 或 Windows 应用控制策略，禁止从开发者工作区目录执行受影响的可执行文件名。建议优先使用基于路径的拒绝规则，并将其范围限定在仓库/工作区根目录，例如 `%USERPROFILE%\source\repos\*\filename.exe`，而非基于哈希的规则，因为攻击者提供的二进制文件哈希值可能各不相同。Windows 并未提供通用的内置规则来仅当特定父进程启动时才阻止任意子可执行文件，因此，感知父进程的强制策略通常需要 EDR 或自定义端点安全产品。
消费级系统：在 IDE 修复之前，请仅在隔离的虚拟机、Windows 沙盒或其他一次性环境中打开不受信任的仓库。对于此问题，不要依赖文件哈希阻止列表。
对一个直截了当的问题的奇怪回应
此次披露中最令人困惑的部分是 Cursor 方面没有任何回应。在七个月的时间里，Mindgard 反复尝试通过所有可用渠道进行联系。最初的披露是直接发送到 Cursor 安全报告电子邮件地址的，该地址在该公司发布的 security.txt 文件中已明确指定。在未收到确认后，又发送了后续跟进邮件。还进行了公开接触，试图找到合适的安全联系人。
最终，Cursor 的首席信息安全官（CISO）做出了回应，并承认内部自动化故障导致预期的 HackerOne 工作流程未能进行。我们被邀请加入私有漏洞赏金计划，并重新提交了报告。
该报告最初被标记为“仅供参考”且超出范围而关闭。在我们对该判定提出异议后，HackerOne 重新打开了报告，复现了该问题，并确认详细信息已传达给 Cursor。然后，一切就停止了。对更新请求的询问无人应答，额外的后续跟进也石沉大海，通过 HackerOne 升级处理也未产生任何有意义的互动，直接联系 Cursor 领导层也得到同样的结果：没有回应。
一个月又一个月过去了，没有任何证据表明修复工作已经开始、工程团队正在积极调查该问题，或者受影响的用户将被告知相关风险。与此同时，Cursor 仍在持续发布新版本。超过 70 个版本来了又去，功能不断推出，公告接连不断，平台也在持续演进。但漏洞依然存在，而反复请求状态更新也未能得到任何有意义的回应。
在某个时刻，对话从漏洞披露转向了一个更令人不安的问题：安全流程到底是为了什么？
漏洞
技术问题本身非常简单。在加载项目时，Cursor 会尝试在多个位置定位 Git 二进制文件。其中一个位置就包括工作区本身。
如果攻击者在仓库根目录中植入了恶意的 git.exe，Cursor 将自动执行它，作为其路径解析逻辑的一部分，而不会发出警告、请求批准，甚至不会提示即将运行来自仓库的可执行内容。
为了安全地演示该问题，Mindgard 使用了一个无害的概念验证：将 Windows 计算器应用程序重命名为 git.exe，并放置在仓库根目录中。只需针对该仓库启动 Cursor，就足以执行它。
下面的截图显示了结果。多个计算器窗口并非由研究人员手动打开。在项目保持打开状态时，Cursor 持续重新执行这个重命名的二进制文件，导致窗口数量随时间不断增加。换句话说，这不是一次性的启动事件，也不是用户触发的操作。Cursor 在正常运行期间，反复调用了工作区内部的可执行内容。
在真实的攻击场景中，计算器将被替换为攻击者控制的代码。
结果是在当前用户权限下执行任意代码，如下 Sysinternals 进程监视器日志所示（最后验证于 2026 年 4 月 30 日，针对 Windows 上的 Cursor 3.2.16 版本）。
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
这个漏洞简单得几乎乏味，而这或许才是最令人担忧的部分。在正常运行过程中，Cursor 会在无需用户交互的情况下，从代码仓库执行一个攻击者可控制的二进制文件。如此直截了当的问题竟能持续数月未修复，这应该让当前所有部署 Cursor 的个人和组织感到担忧。
本次披露为何不同
大多数协调披露遵循一个熟悉的模式：
- 漏洞被报告。
- 对话开始。
- 讨论严重程度。
- 工程团队展开调查。
- 修复方案被开发出来。
- 用户得到保护。
- 随后进行公开披露。
这一流程之所以有效，是因为所有各方都有一个共同目标：降低风险。
不幸的是，这个案例从未进入风险降低的阶段。在七个月且供应商未参与之后，是时候质疑这样一个简单且影响巨大的漏洞是否还会得到修复了。
安全研究人员理解修复需要时间，尤其是在庞大且快速演变的软件平台内部。然而，当数月过去，既无沟通、也无更新、更无可见进展时，耐心就很难再站得住脚。用户理应获得针对基本威胁的基本保护，而当供应商在继续分发受影响软件的同时停止沟通时，研究人员最终面临一个令人不安的抉择：
- 保持沉默，让用户在虚假的安全假设下继续使用。
- 或者，公开披露该问题，以便各组织能够做出知情的风险决策。
我们认为用户理应获得这些信息。全面披露是漏洞披露中的核选项，仅用于其他所有途径都已失败的情况。它之所以存在，是有原因的：当供应商停止沟通时，用户不应被蒙在鼓里。
当创新不再倾听时会发生什么？
最明显的问题也是最简单的：为什么这个问题至今未被修复？
该漏洞既不隐蔽也不难复现，攻击路径直接且影响严重。Cursor 对此反应平淡，引发了更广泛的问题：
- 现代漏洞赏金计划是否已不堪重负？
- 漏洞赏金计划是否因 Mythos 等能力日益强大的模型而超负荷运转？
- Cursor 是否因忙于收购 SpaceX 而将用户安全置于次要位置？
- 当涉及数十亿美元的利益时，用户安全是否还值得关注？
安全行业多年来一直鼓励研究人员使用协调披露渠道。这些渠道依赖于响应迅速的分类流程，以及供应商评估和处理上报报告的能力。然而，随着 AI 产品激增，安全发现的数量急剧增加。其中许多发现是新颖的，无法简单归入传统的漏洞类别。与此同时，我们依赖了近二十年的分类流程正在迅速失效，因为其构建所依据的核心假设在 AI 新兴世界面前正在瓦解。
如果披露渠道不堪重负，行业应该直言不讳。研究人员、客户和用户理应获得透明度。
遗憾的是，随着优先级这一令人不安的问题日益突出，情况可能并非如此。与许多其他公司一样，Cursor 一直处于巨大增长、投资和行业关注的中心。该公司正在快速扩张，但从外部来看，很难将这种增长与一个简单的任意代码执行漏洞缺乏可见进展这一事实相协调。
快速增长带来了解决安全故障的责任，同时也要求将用户视为有价值的客户，而非购买实验品。他们信任的是能够访问源代码、凭证、专有知识产权以及日益增强的自主能力的生产软件。
信任需要问责，问责需要沟通。当用户、研究人员和披露平台花费数月寻求基本状态更新却无果时，这种问责就变得难以看到或相信。
更大的问题
这一披露所涉及的远不止一个名为 git.exe 的可执行文件，而是触及了软件领域的信任根基。AI 公司经常要求用户授予前所未有的代码、代码仓库、终端、密钥和工作流访问权限，这使得建议与行动之间的界限日益模糊。
行业内的说法是，这些系统值得信任，因为它们能提高生产力。但历史一次次告诉我们，信任不应因为某物有用就被给予。信任必须通过行为来赢得。这种行为体现在公司如何响应安全报告、如何与受影响用户沟通，以及如何优先处理修复工作。
当直截了当的漏洞在数月内得不到解决，且缺乏有意义的沟通时，用户就不得不重新评估对这份信任的假设。
我们为何选择完全公开披露
与许多安全研究团队一样，Mindgard 更倾向于协同披露。目标始终是安全第一，公开第二。
但协同披露只有在存在协同的情况下才有效。在首次披露七个月后，我们没有任何迹象表明用户正在得到保护、修复工作正在进行，或者受影响的组织已被告知。在这一点上，隐瞒信息不再服务于用户，它服务于沉默。
出于这个原因，Mindgard 将发布此漏洞的全部细节。使用 Cursor 的组织理应有机会评估自身风险、实施补偿性控制措施，并就其安全态势做出明智决策。
用户安全必须放在首位，即使披露会带来不便。
尤其是在披露会带来不便的时候。
时间线
| 日期 | 行动 |
|---|---|
| 2025 年 12 月 15 日 | Mindgard 发现漏洞 |
| 2025 年 12 月 15 日 | 向 security-reports@cursor.com 报告漏洞 |
| 2025 年 12 月 18 日 | 跟进请求确认收到 |
| 2026 年 1 月 13 日 | Mindgard 在 LinkedIn 上发布帖子，请求联系 Cursor 相关人员以提供协助。一位用户在评论中提到了 Cursor 的 CISO。 |
| 2026 年 1 月 15 日 | Cursor 的 CISO 回应了那封邮件，指出原本应邀请 Mindgard 加入 HackerOne 私有漏洞奖励计划的自动化流程出现了故障。CISO 手动将 Mindgard 邀请至该漏洞奖励计划。 |
| 2026 年 1 月 15 日 | 通过 HackerOne 提交漏洞 |
| 2026 年 1 月 16 日 | 报告最初被标记为“仅供参考”且超出范围，并已关闭 |
| 2026 年 1 月 16 日 | Mindgard 对判定提出异议 |
| 2026 年 1 月 16 日 | 报告在成功复现后重新开启 |
| 2026 年 1 月 20 日 | HackerOne 确认已将报告送达 Cursor |
| 2026 年 2 月 16 日 | 请求更新，未收到回复 |
| 2026 年 3 月 3 日 | 请求更新，未收到回复 |
| 2026 年 3 月 17 日 | 直接联系 Cursor CISO 请求更新 |
| 2026 年 3 月 18 日 | HackerOne 表示已联系 Cursor |
| 2026 年 4 月 1 日 | 请求更新，未收到回复 |
| 2026 年 4 月 1 日 | HackerOne 确认 Cursor 未提供任何更新 |
| 2026 年 6 月 1 日 | Mindgard 通知 HackerOne 打算公开披露 |
| 2026 年 6 月 3 日 | HackerOne 提供披露指导 |
| 2026 年 7 月 14 日 | 本篇博文发布。 |
Cursor 0day: When Full Disclosure Becomes the Only Protection Left
Aaron Portnoy
July 14, 2026
Updated:
June 17, 2026
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.
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:
- A vulnerability is reported.
- A dialogue begins.
- Severity is discussed.
- Engineering teams investigate.
- Fixes are developed.
- Users are protected.
- 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:
- Remain silent and allow users to operate under a false assumption of safety.
- 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
| Date | Action |
|---|---|
| Dec 15, 2025 | Vulnerability discovered by Mindgard |
| Dec 15, 2025 | Vulnerability reported to security-reports@cursor.com |
| Dec 18, 2025 | Follow-up requesting confirmation of receipt |
| Jan 13, 2026 | Mindgard created a LinkedIn post requesting a contact at Cursor to assist. Cursor CISO is mentioned by a user in the comments. |
| Jan 15, 2026 | Cursor CISO responds to the e-mail thread indicating an automation failed that was supposed to invite to the HackerOne private bounty program. CISO manually invites Mindgard to the bounty program. |
| Jan 15, 2026 | Vulnerability submitted through HackerOne |
| Jan 16, 2026 | Report initially closed as Informative and out of scope |
| Jan 16, 2026 | Mindgard challenges determination |
| Jan 16, 2026 | Report reopened after successful reproduction |
| Jan 20, 2026 | HackerOne confirms delivery to Cursor |
| Feb 16, 2026 | Update requested, no response received |
| Mar 3, 2026 | Update requested, no response received |
| Mar 17, 2026 | Direct outreach to Cursor CISO requesting update |
| Mar 18, 2026 | HackerOne indicates Cursor has been contacted |
| Apr 1, 2026 | Update requested, no response received |
| Apr 1, 2026 | HackerOne confirms no update from Cursor |
| Jun 1, 2026 | Mindgard informs HackerOne of intent to disclose publicly |
| Jun 3, 2026 | HackerOne provides disclosure guidance |
| Jul 14 2026 | This blog post published. |