光标 0day：完全披露成为唯一保护时

作者：袖梨 2026-07-15

有时，安全研究会发现需要大量解释的深层技术漏洞。这不是其中之一。

这个错误很简单。开发人员在Windows上的Cursor中打开一个存储库，如果该存储库在项目根目录中包含恶意git.exe，Cursor将自动执行它。没有点击、提示、批准对话框或警告。结果是任意代码执行。

鉴于 Cursor 是最广泛采用的人工智能辅助开发环境之一（超过 700 万活跃用户、超过 100 万每日用户、超过 100 万付费用户、超过 5 万家公司使用），并且其报告的市场价格为 600 亿美元，可以公平地假设存在一定程度的对安全实践的尊重，但这个问题表明情况并非如此。

Mindgard 于 2025 年 12 月 15 日首次发现该漏洞。我们在同一天报告了该漏洞，此后多次报告。六个多月和 197 多个新版本过去后，该问题仍然存在于最新测试的 Cursor 版本中。

该漏洞不是理论上的，也不依赖于复杂的利用链、提示注入、模型操纵、越狱、内存损坏或复杂的攻击者交易技术。利用该漏洞只需要开发人员在根目录下的存储库中打开一个包含 git.exe 二进制文件的项目。

光标用户现在应该做什么

企业/托管 Windows 系统：作为托管 Windows 系统的临时缓解措施，管理员可以使用 AppLocker 或 Windows 应用程序控制策略来拒绝从开发人员工作区目录执行受影响的可执行文件名称。首选基于路径的拒绝规则，范围仅限于存储库/工作空间根目录，例如 %USERPROFILE%sourcerepos*filename.exe ，而不是基于哈希的规则，因为攻击者提供的二进制文件可能会因哈希而异。 Windows 不提供通用的内置规则来仅在由特定父进程启动时阻止任意子可执行文件，因此父级感知强制执行通常需要 EDR 或自定义端点安全产品。

消费者系统：在 IDE 修补之前，仅在隔离的 VM、Windows Sandbox 或其他一次性环境中打开不受信任的存储库。不要依赖文件哈希阻止列表来解决此问题。

对简单问题的奇怪反应

此披露中最令人困惑的部分是 Cursor 没有响应。在七个月的时间里，Mindgard 反复尝试通过所有可用的渠道进行参与。最初披露的信息直接发送到 Cursor 的安全报告电子邮件地址，如该公司发布的 security.txt 文件中指定的那样。在未收到确认的情况下发送了后续信息。我们进行了公开宣传，试图确定适当的安全联系人。

最终，Cursor 的 CISO 做出回应并承认内部自动化故障导致预期的 HackerOne 工作流程无法进行。我们被邀请参加私人错误赏金计划并重新提交了报告。

该报告最初被视为信息性且超出范围而关闭。在我们对这一决定提出质疑后，HackerOne 重新打开了报告，重现了该问题，并确认详细信息已发送给 Cursor。然后一切都停止了。更新请求没有得到答复，其他后续行动也没有得到回应，通过 HackerOne 升级没有产生任何有意义的参与，直接联系 Cursor 领导层也得到了同样的结果：没有回应。

一个月又一个月过去了，没有证据表明补救措施已经开始，工程团队正在积极调查该问题，或者受影响的用户将被告知风险。与此同时，Cursor 继续发布版本。随着功能的发布、公告的不断发布以及平台的发展，70 多个版本不断出现和消失。但该漏洞仍然存在，并且反复请求状态更新没有得到任何有意义的响应。

在某些时候，谈话从漏洞披露转向一个更令人不安的问题：安全流程到底是用来做什么的？

技术问题本身非常简单。加载项目时，Cursor 会尝试跨多个位置查找 Git 二进制文件。这些位置之一包括工作区本身。

如果攻击者在存储库根目录中植入恶意 git.exe，Cursor 将作为其路径解析逻辑的一部分自动执行它，而不会发出警告、批准，甚至不会指示存储库中的可执行内容即将运行。

为了安全地演示该问题，Mindgard 使用了无害的概念验证：Windows 计算器应用程序，重命名为 git.exe ，放置在存储库的根目录中。只需针对该存储库启动 Cursor 就足以执行它。

下面的屏幕截图显示了结果。多个计算器窗口不是研究人员手动打开的。当项目保持打开状态时，光标继续重新执行重命名的二进制文件，导致随着时间的推移出现更多实例。换句话说，这不是一次性启动事件或用户触发的操作。光标在正常操作期间重复调用工作区内部的可执行内容。

使用 Windows 计算器进行无害的概念验证，并将其重命名为 git.exe。打开项目后，光标会从存储库根目录重复执行二进制文件。

在真实的攻击场景中，计算器将简单地替换为攻击者控制的代码。

结果是在当前用户的权限下执行任意代码，如以下 Sysinternals 进程监视器日志所示（最后一次验证时间为 2026 年 4 月 30 日，针对 Windows 上的 Cursor 版本 3.2.16。）

该漏洞的简单性几乎令人厌烦，但这可能是最令人担忧的部分。在正常操作期间，Cursor 从存储库执行攻击者控制的二进制文件，无需用户交互。事实上，这样一个简单的问题可能会持续数月而不进行修复，这一事实应该引起当前部署 Cursor 的每个个人和组织的关注。

为什么这次披露有所不同

大多数协调披露都遵循熟悉的模式：

报告了一个漏洞。
对话开始。
讨论了严重性。
工程团队进行调查。
已开发修复程序。
用户受到保护。
公开披露如下。

这个过程之所以有效，是因为所有各方都有一个共同的目标：降低风险。

不幸的是，此案从未达到降低风险的阶段。七个月后，没有供应商参与，是时候质疑是否会针对如此简单、高影响力的漏洞进行修复了。

安全研究人员明白，修复需要时间，特别是在大型且快速发展的软件平台内。然而，当几个月过去了，没有沟通、更新或明显的进展时，耐心就变得很难证明是合理的。用户应该获得针对基本威胁的基本保护，当供应商在继续分发受影响的软件的同时停止通信时，研究人员最终将面临一个令人不安的决定：

保持沉默并允许用户在错误的安全假设下进行操作。
或者，公开披露该问题，以便组织可以做出明智的风险决策。

我们相信用户应该获得这些信息。完全披露是漏洞披露的核心选项，保留给所有其他路径都失败的情况。它的存在是有原因的：当供应商停止沟通时，用户不应该被蒙在鼓里。

当创新停止倾听时会发生什么？

最明显的问题也是最简单的：为什么这个问题还没有得到解决？

该漏洞既不微妙也不难以重现，具有直接的执行路径和严重影响。 Cursor 的平淡反应引发了更广泛的问题：

现代错误赏金计划是否变得超载？
错误赏金计划是否因 Mythos 等模型能力日益增强而超载？
Cursor 是否专注于收购 SpaceX，而忽视了用户安全？
当数十亿美元受到威胁时，用户安全还有什么顾虑吗？

安全行业多年来一直鼓励研究人员使用协调的披露渠道。这些渠道依赖于响应迅速的分类流程以及有能力评估传入报告并采取行动的供应商。然而，随着人工智能产品的激增，安全问题的数量正在急剧增加。其中许多发现都是新颖的，并不完全适合传统的漏洞类别。与此同时，我们近二十年来所依赖的分类流程正在迅速失败，因为它们所建立的核心假设在新兴的人工智能世界中崩溃了。

如果披露渠道变得不堪重负，业界应该这么说。研究人员、客户和用户应该保持透明度。

遗憾的是，随着令人不安的优先级问题日益增多，情况可能并非如此。与许多其他公司一样，Cursor 一直处于巨大增长、投资和行业关注的中心。该公司正在迅速扩张，但从外部来看，很难将这种增长与在直接任意代码执行漏洞上缺乏明显进展相协调。

快速增长带来了解决安全故障的责任，同时也要求将用户视为有价值的客户，而不是购买实验。他们信任生产软件可以访问源代码、凭证、专有知识产权以及越来越多的自主功能。

信任需要责任，责任需要沟通。当用户、研究人员和披露平台花费数月时间寻求基本状态更新但没有成功时，这种责任就变得很难看到或相信。