Cursor 0day：完全披露成为唯一的保护手段

# Cursor 0day：当全面披露成为最后的保护手段 - Mindgard 来源：https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left ## 核心要点 打开项目后，Cursor 会试图在多个位置查找 git 二进制文件，包括当前工作空间。通过创建一个在根目录植入了恶意 git.exe 的仓库，IDE 将直接执行该文件，无需用户交互或确认。此类操作会持续反复发生。 有时安全研究会涉及极其复杂的技术漏洞，需要长篇解释。但这个漏洞不是那样。 这个漏洞非常简单。开发者如果在 Windows 系统上用 Cursor 打开一个仓库，而该仓库的项目根目录下包含一个恶意的 git.exe，Cursor 会自动执行它。无需点击、提示、批准对话框或任何警告。结果是任意代码执行。 鉴于 [Cursor](https://cursor.com/) 是业界最广泛使用的 AI 辅助开发环境之一（700 万+ 活跃用户、100 万+ 日活用户、100 万+ 付费用户、被 5 万+ 公司采用），且其 [报道市场估值达 600 亿美元](https://www.forbes.com/sites/richardnieva/2026/06/08/cursor-4-billion-annualized-revenue/)，人们有理由认为它具备一定程度的安全实践尊重，但这个问题表明事实并非如此。 该漏洞由 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 文件](https://cursor.com/.well-known/security.txt) 所指定）。未收到确认后发送了后续跟进。还进行了 [公开联系](https://www.linkedin.com/posts/aaronportnoy_can-anyone-put-me-in-touch-with-a-security-share-7416965166954868736-agkL/)，试图找到合适的安全联系人。 最终，Cursor 的 CISO 回应并承认内部自动化故障导致预期的 HackerOne 工作流未能启动。我们被邀请加入私有的漏洞赏金计划，并重新提交了报告。 最初报告被关闭，状态为“信息性”且超出范围。在我们质疑这一判定后，HackerOne 重新打开报告，复现了问题，并确认详细信息已交付给 Cursor。然后一切都停止了。请求更新未获答复，多次后续跟进没有回应，通过 HackerOne 升级也未产生有意义的参与，直接联系 Cursor 领导层同样石沉大海：没有回应。 一个月又一个月过去，没有证据表明修复已开始、工程团队正在积极调查，或者受影响用户将获知风险。与此同时，Cursor 继续发布版本。超过 70 个版本随着功能发布、公告持续和平台演进而迭代。但漏洞仍然存在，反复请求状态更新均未得到实质回应。 在某个时刻，对话从漏洞披露转向了一个更令人不安的问题：安全流程究竟是为了什么？ ## **漏洞本身** 技术问题本身非常直接。当加载项目时，Cursor 会在多个位置尝试定位 Git 二进制文件。其中一个位置包括工作空间本身。 如果攻击者在仓库根目录植入了恶意的 `git.exe`，Cursor 将在其路径解析逻辑中自动执行它，而不会发出警告、请求批准，甚至不会提示用户仓库中的可执行内容即将运行。 为了安全地展示问题，Mindgard 使用了一个无害的概念验证：将 Windows 计算器应用程序重命名为 `git.exe`，放在仓库根目录。仅需在 Cursor 中打开该仓库，即可执行它。 下面的截图显示了结果。多个计算器窗口并非由研究员手动打开。在项目保持打开状态期间，Cursor 持续重新执行重命名的二进制文件，导致更多实例随时间出现。换句话说，这不是一次性的启动事件或用户触发的操作。Cursor 在正常运行期间反复调用了工作区内的可执行内容。 *无害的概念验证：将 Windows 计算器重命名为 git.exe。项目打开后，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 的个人和组织的担忧。 ## **为什么这次披露不同** 大多数协调披露遵循一个熟悉的模式： 1. 发现漏洞并报告。 2. 开始对话。 3. 讨论严重性。 4. 工程团队调查。 5. 开发修复。 6. 用户得到保护。 7. 公开披露。 该流程之所以有效，是因为所有参与方都有共同目标：降低风险。 不幸的是，这个案例从未进入风险降低阶段。经过七个月且供应商毫无参与之后，是时候质疑这种简单、高影响漏洞的修复是否还会发生了。 安全研究人员理解修复需要时间，尤其是在大型且快速演变的软件平台中。然而，当数月过去没有任何沟通、更新或可见进展时，耐心就难以维持。用户理应得到针对基本威胁的基本保护，而当供应商停止沟通却继续分发受影响软件时，研究人员最终面临一个令人不安的选择： 1. 保持沉默，让用户在虚假的安全感中操作。 2. 或者公开披露问题，使组织能够做出有依据的风险决策。 我们认为用户有权了解信息。全面披露是漏洞披露的核选项，只有在所有其他路径都失败时才保留。它的存在有理由：当供应商停止沟通时，用户不应被蒙在鼓里。 ## **当创新停止倾听时会发生什么？** 最明显的问题也是最简单的：为什么还没有修复？ 这个漏洞既不微妙也不难以复现，执行路径直接且影响严重。Cursor 的冷淡回应引发更广泛的问题： - 现代漏洞赏金计划是否不堪重负？ - 由于模型（如 Mythos）能力越来越强，漏洞赏金计划是否过于繁忙？ - Cursor 是否因收购 SpaceX 而分心，从而降低了用户安全优先级？ - 当数十亿美元处于风险中时，用户安全是否还有任何关注？ 安全行业多年来一直鼓励研究人员使用协调披露渠道。这些渠道依赖于响应迅速的分类流程以及供应商评估和处理传入报告的能力。然而，随着 AI 产品的激增，安全发现的数量急剧增加。其中许多发现是新颖的，并不完全符合传统的漏洞分类。与此同时，我们依赖了近二十年的分类流程正在迅速失效，因为其核心假设在新兴的 AI 世界中逐渐瓦解。 如果披露通道不堪重负，行业应该承认。研究人员、客户和用户理应得到透明度。 遗憾的是，随着对优先级的令人不安的疑问日益增多，情况可能并非如此。与许多其他公司一样，Cursor 一直处于巨大增长、投资和行业关注的中心。公司正在快速扩张，但从外部看，很难将这种增长与在这样一个直接的任意代码执行漏洞上没有可见进展的情况相调和。 快速增长带来了处理安全漏洞的责任，同时也要求将用户视为有价值的客户而非购买实验品。他们信任生产级软件，使其访问源代码、凭据、专有知识产权，以及日益增长的自主能力。 信任需要问责，问责需要沟通。当用户、研究人员和披露平台花费数月寻求基本状态更新却无果时，这种问责就变得难以看到或相信。 ## **更大的问题** 这次披露超越了单一的名为 git.exe 的可执行文件，触及了软件中的信任问题。AI 公司通常要求用户授予前所未有的访问级别：代码、仓库、终端、密钥和工作流程，这些正日益模糊建议与行动之间的界限。 行业叙述是这些系统值得信任，因为它们能提高生产力。但历史反复告诉我们，信任不应仅仅因为某样东西有用就被赋予。它应通过行为来赢得。这种行为体现在公司如何回应安全报告、与受影响用户沟通、以及优先处理修复。 当直接漏洞在数月内得不到解决且缺乏有意义的沟通时，用户就不得不重新评估关于这种信任的假设。 ## **为什么我们要全面披露** 像许多安全研究团队一样，Mindgard 倾向于协调披露。目标始终是安全第一，宣传第二。 但协调披露只有在存在协调时才有效。初始披露七个月后，我们没有任何迹象表明用户正在受到保护、修复正在进行中，或者受影响组织已被告知。而在这一点上，隐瞒信息不再服务于用户——它服务于沉默。 出于这个原因，Mindgard 正在发布此漏洞的全部细节。使用 Cursor 的组织应有机会评估自身风险、实施补偿控制措施，并就其安全态势做出明智决策。 用户安全必须放在首位，即使在披露变得令人不舒服的时候。 尤其是在披露变得令人不舒服的时候。 ## **时间线** **日期** | **行动** --- | --- 2025年12月15日 | Mindgard 发现漏洞 2025年12月15日 | 报告提交至 [email protected] 2025年12月18日 | 跟进确认收到 2026年1月13日 | Mindgard 在 LinkedIn 发帖请求协助联系 Cursor。用户在评论中提到 Cursor CISO。 2026年1月15日 | Cursor CISO 回复邮件，称自动化故障导致未发送 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日 | 本博客文章发布