日期：2026-07-15
主题：Cursor 完全披露：AI 编程 IDE 中的任意代码执行漏洞
原文：Cursor 完全披露：AI 编程 IDE 中的任意代码执行漏洞
来源：Lobsters
领域：🔒 安全/网络
2025 年 12 月 15 日，安全研究团队 Mindgard 向 Cursor 官方安全邮箱发送了一份漏洞报告——一个影响所有 Windows 版 Cursor 用户的严重 0day 漏洞。七个月后、197 个版本迭代之后，这个漏洞依然存在于最新版的 Cursor 中。2026 年 7 月 14 日，Mindgard 选择完全披露（Full Disclosure）。
这不是一个需要复杂利用链的漏洞。它简单到令人不安：只要你用 Cursor 打开一个仓库，而仓库根目录下有一个恶意的 git.exe，Cursor 就会自动执行它——不需要你点击任何按钮，不需要你确认任何弹窗，甚至不会给你任何警告。
本文将还原这个漏洞的技术细节、Mindgard 与 Cursor 之间长达七个月的沟通历程，以及完全披露背后那些值得整个行业反思的问题。
「有时安全研究发现了需要好几页来解释的深度技术漏洞，」Aaron Portnoy 在博客中写道，「但这个漏洞不在此列。」
当 Cursor 在 Windows 上加载一个项目时，它需要定位 Git 二进制文件来执行各种版本控制操作。问题在于 Cursor 的路径搜索逻辑：它不仅会在系统 PATH 中寻找 Git，还会把工作区目录本身也纳入搜索范围。
这意味着如果仓库根目录下存在一个 git.exe，Cursor 会优先——或者说错误地——找到并使用它。攻击者只需要创建一个包含恶意 git.exe 的仓库，然后引诱目标用 Cursor 打开它即可。
Mindgard 用了一个无害的 PoC 来演示：他们把 Windows 计算器（Calculator.exe）重命名为 git.exe，放在仓库根目录下。仅仅打开这个仓库，计算器窗口就弹出来了——而且不止一个。Cursor 会反复执行这个二进制文件，只要项目保持打开状态，越来越多的实例就会不断涌现。
这不是一次性启动事件，也不是用户触发的操作。Cursor 在工作区正常运行时，反复调用了来自仓库内部的可执行内容。
— Aaron Portnoy
Mindgard 提供了 Sysinternals Process Monitor 的日志截图（最后一次验证于 2026 年 4 月 30 日，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
注意命令行参数：git rev-parse --show-toplevel——这是 Cursor 在正常启动流程中自动调用的 Git 命令，用于确定仓库根目录。只不过在这次调用中，执行的不是系统安装的 Git，而是攻击者精心准备的恶意负载。
这个漏洞的危险性不在于技术复杂度，而在于它的利用条件几乎总是满足：
更令人担忧的是，这个漏洞利用了开发者对 AI 编程工具的天然信任。开发者将 Cursor 接入源代码、凭证、API Key、专有知识产权，甚至赋予了它越来越多的自主操作能力——而它却在没有任何防护的情况下执行来自不可信来源的代码。
漏洞本身很简单，但后续的故事远比漏洞复杂。
| 日期 | 事件 |
|---|---|
| 2025-12-15 | Mindgard 通过 Cursor 官方安全邮箱（security.txt 指定）提交漏洞报告 |
| — | 多日无回应，Mindgard 发送跟进邮件 |
| — | 公开渠道尝试联系未果 |
| 后续 | Cursor CISO 终于回应，承认内部自动化故障导致 HackerOne 流程未触发 |
| — | Mindgard 受邀加入私有漏洞赏金计划，重新提交报告 |
| — | 报告被标记为「Informative / Out of Scope」，关闭 |
| — | Mindgard 提出异议后，HackerOne 重新打开报告、复现漏洞，确认信息已送达 Cursor |
| 此后 | 一切陷入沉默——跟进邮件无回复、HackerOne 渠道无响应、直接联系 Cursor 高层无反馈 |
| 2026-07-14 | 七个月、197+ 个版本发布后，漏洞仍未修复。Mindgard 选择完全披露 |
Mindgard 在博客中坦诚地解释了为什么走到这一步：
大多数协同披露都遵循一个熟悉的模式：漏洞上报 → 开始对话 → 讨论严重性 → 工程团队调查 → 开发修复 → 保护用户 → 公开披露。
这个过程之所以有效，是因为所有参与方共享同一个目标：降低风险。
但在这个案例中，流程从未进入「降低风险」阶段。七个月后，没有修复、没有沟通、没有对受影响用户的告知。Mindgard 面临一个艰难的选择：
完全披露是漏洞披露的核选项，保留给所有其他路径都已失败的情况。它的存在是有理由的：当厂商停止沟通时，用户不应该被蒙在鼓里。
这个案例引发了一系列远比单个漏洞更深层的问题：
过去二十年建立的安全行业协调披露机制，正在 AI 时代承受前所未有的压力。AI 产品的迭代速度远超传统软件——Cursor 在七个月内发布了 197 个版本，但安全团队的处理能力并没有同步增长。更糟糕的是，AI 领域的漏洞往往新颖且不符合传统分类，让现有的漏洞评审流程无所适从。
但问题是，如果披露管道正在过载，行业应该公开说出来，而不是让研究人员在真空中等待。研究员、客户和用户都值得获得透明度。
Cursor 在这七个月中持续发布新功能、进行市场宣传、甚至传出收购 SpaceX 的消息。但一个最基本的安全问题——git.exe 路径搜索——却始终未被修复。这让人不禁质疑：当一家公司估值达到 600 亿美元时，用户安全还在优先级的哪个位置？
AI 编程工具要求用户授予前所未有的访问权限：源代码、凭证、终端、API Key，以及越来越强的自主行动能力。行业叙事说这些系统值得信任，因为它们能提高生产力。但历史一次又一次地告诉我们：信任不应该因为有用而被授予，它应该通过行为来赢得。
而行为体现在一家公司如何响应安全报告、如何与受影响的用户沟通、以及如何优先处理修复工作。
Cursor 的这个漏洞在技术层面几乎不值一提——它只是一个错误的路径搜索。但它在安全伦理层面提出的问题，值得整个 AI 工具行业深思。
对 Cursor 用户而言，在官方修复发布之前：
git.exe。优先使用基于路径的拒绝规则（如 %USERPROFILE%\source\repos\*\git.exe），而非哈希规则。我们希望这个故事能成为一个转折点——不只是为了 Cursor，而是为了整个 AI 编程工具类别。完全披露不应该是唯一剩下的保护手段，也不应该是研究人员最后的选择。但在厂商停止倾听的时候，它至少确保了用户不会被蒙在鼓里。
用户安全必须放在第一位，即使披露本身会令人不适。
尤其是在披露令人不适的时候。