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 日 | 本篇博文发布。 |