Cursor 0day 漏洞：全面披露成为最后保护

背景

Cursor 是当前最广泛使用的 AI 辅助开发环境之一，拥有超过 700 万活跃用户、每日 100 万+ 日活、100 万+ 付费用户，并被 5 万+ 企业采用。其估值高达 600 亿美元。在这样的体量下，安全实践理应受到高度重视。然而，2025 年 12 月 15 日，安全研究机构 Mindgard 发现了一个极其简单却危害巨大的 0day 漏洞——Cursor 在加载项目时会自动执行仓库根目录下的 git.exe 二进制文件，无需用户任何交互。该漏洞在报告后的七个月内（截至 2026 年 4 月 30 日测试的最新版本）仍未修复，且厂商 Cursor 的响应近乎沉默。本文是 Mindgard 在 Hacker News 上发布的公开披露，旨在让用户了解风险并采取自我保护措施。

核心内容

漏洞细节

该漏洞不涉及复杂的利用链、提示注入、模型操纵、内存破坏或高级攻击技巧。它简单到令人不安：

• 触发方式：在 Windows 系统上，开发者打开一个包含恶意 git.exe 的仓库，Cursor 会自动执行该文件。
• 无需交互：没有点击确认、弹窗批准或任何警告。结果是任意代码执行。
• 反复执行：当项目保持打开时，Cursor 会持续重新执行该二进制文件——Mindgard 使用无害的 Windows 计算器程序（重命名为 git.exe）作为概念验证，仅通过打开仓库就弹出了多个计算器窗口，且不是手动触发，而是 Cursor 在正常操作期间反复调用工作空间内的可执行内容。

技术原理

Cursor 在加载项目后，会尝试在多个位置查找 Git 二进制文件，其中包括当前工作区本身。攻击者在仓库根目录植入一个恶意 git.exe，Cursor 会自动执行它作为路径解析逻辑的一部分。以下是从 Sysinternals Process Monitor 日志中截取的实例（2026 年 4 月 30 日，Cursor 版本 3.2.16）：

4:25:12.6209706 PM Cursor.exe 54880 Process Create c:\Users\aport\...\git_exec0001\git.exe SUCCESS PID: 48972, Command line: git rev-parse --show-toplevel "C:\...\Cursor.exe" C:\...\Cursor.exe

报告过程

• 2025 年 12 月 15 日：Mindgard 首次发现并立即通过 Cursor 官方 security.txt 中指定的安全报告邮箱提交报告。
• 多次跟进：由于未收到确认回复，Mindgard 通过公开渠道尝试联系。
• 最终联系到 CISO：Cursor 的 CISO 最终回应称内部自动化故障导致 HackerOne 流程未触发，并邀请 Mindgard 加入私有漏洞赏金计划。Mindgard 重新提交报告。
• HackerOne 介入：最初报告被标记为“信息性”且不在范围。Mindgard 质疑后，HackerOne 重新打开报告、复现问题并确认已将详情交付 Cursor。
• 随后停止：所有状态更新请求均无回应，通过 HackerOne 升级也未产生实质性互动，直接联系 Cursor 领导层同样石沉大海。
• 七个月后：Cursor 发布了 197+ 个新版本（超过 70 个版本迭代），但漏洞始终存在。Mindgard 最后一次验证时间：2026 年 4 月 30 日，Cursor 3.2.16。

临时缓解措施

• 企业/托管 Windows 系统：管理员可使用 AppLocker 或 Windows App Control 策略，拒绝执行开发者工作区目录中受影响的执行文件名。推荐基于路径的拒绝规则（例如 %USERPROFILE%\source\repos\*\git.exe），而非哈希规则，因为攻击者提供的二进制文件哈希可变。Windows 没有内置规则能仅当由特定父进程启动时阻止子进程，因此父进程感知的强制执行一般需要 EDR 或自定义端点安全产品。
• 个人用户：在 IDE 修补前，仅在隔离的虚拟机、Windows Sandbox 或其他一次性环境中打开不受信任的仓库。不要依赖文件哈希黑名单。

关键要点

• 漏洞极简且危害极大：无需用户点击，只需打开包含恶意 git.exe 的仓库即可实现任意代码执行，且执行会反复发生。
• 报告时间线长达七个月：从 2025 年 12 月 15 日首次披露到 2026 年 4 月 30 日最后验证，漏洞始终存在于最新版本中。
• 厂商响应严重缺失：尽管最终通过 CISO 进入 HackerOne 流程，且 HackerOne 确认复现，Cursor 后续再无任何实质性沟通、修复或更新。
• 用户面临虚假安全感：在厂商持续发布新功能的同时，用户根本不知道有如此简单的攻击面存在。
• 全面披露的合理性：在厂商停止沟通、用户安全无法保障的情况下，公开披露成为最后且必要的保护手段。研究人员面对两难：沉默（用户误以为安全）或公开（让组织做出知情风险决策）。
• 临时缓解措施有限：Windows 原生缺乏基于父进程的拦截能力，企业需依赖 EDR 或自定义安全产品；个人用户仅能通过隔离环境规避风险。
• 问题简单到令人担忧：如此基础的路径解析安全问题（执行工作区内的未知可执行文件）在拥有数十亿美元估值和百万级用户的 IDE 中持续数月而未修复，反映了安全流程的严重失效。

意义与影响

• 对 Cursor 用户的直接影响：任何在 Windows 上使用 Cursor 的开发者和企业，如果打开过不受信任的仓库，都可能已暴露在远程代码执行风险之下。攻击者可以轻易植入恶意 git.exe 并通过社交工程（如 GitHub PR、邮件附件、恶意仓库链接）诱导开发者打开项目。
• 对 AI 辅助开发工具行业的警示：Cursor 作为 AI 编程工具的头部产品，其安全漏洞的简单性和长期未修复状态表明：即使是最基本的安全审查也可能被忽视。这对于其他类似产品（如 Copilot、Codeium 等）是重要警示——它们也可能存在类似的工作区路径执行问题。
• 协调披露机制的失效：协调披露（Coordinated Disclosure）通常期望厂商在合理时间内修复漏洞，但 Cursor 的案例显示，当厂商选择沉默、HackerOne 流程也无法推动进展时，研究人员只能走向全面披露。这削弱了行业对安全合作流程的信任。
• 对用户与企业的安全建议：
  • 在 Cursor 发布修复补丁之前，应限制其在生产环境或敏感网络中的使用。
  • 对于企业客户，应立即评估内部 Cursor 使用情况，并实施 AppLocker 等临时策略。
  • 个人开发者应养成在隔离环境中打开不信任仓库的习惯，并关注公开漏洞公告。
• 长期影响：该事件的公开披露可能导致更多研究人员关注 Cursor 和其他 AI 工具的攻击面，进而加速漏洞发现；同时，Cursor 需要重建安全信誉——如果再不修复，可能面临用户流失、企业禁用甚至法律风险。