Cursor被曝Windows版漏洞：打开项目自动执行伪装git.exe，七个月未修复

安全公司 Mindgard 披露，Windows 版 Cursor 在打开项目时，会自动执行仓库根目录下伪装成 git.exe 的程序。全程不需要用户点击、确认，也没有任何弹窗提示。这个问题 2025 年 12 月 15 日被上报，直到 2026 年 7 月 14 日才公开，中间隔了七个月。

真正值得盯的不是又一个“AI 编程工具”的安全漏洞标签，而是 Cursor 把不受信任的仓库变成了免交互的代码执行入口，以及它的响应速度能不能配得上企业级部署规模。目前所有细节都来自 Mindgard 单方披露，Cursor 没有公开确认，也没有第三方复现，这点读者需要自己心里有数。

触发机制：一个文件名就能拿到当前用户权限

Mindgard 的复现方法很简单：把 Windows 自带的计算器程序改名为 git.exe，放进仓库根目录，用 Cursor 打开这个项目。计算器窗口自己弹了出来。项目保持打开状态时，它还会反复触发，不止一次。

问题出在 Cursor 加载项目时查找 Git 可执行文件的逻辑上。它会在几个路径里找 git.exe，包括工作区根目录，找到就直接运行，不检查来源。按 Mindgard 的说法，最后一次验证是 2026 年 4 月 30 日，版本号 3.2.16，问题依然存在。

这类攻击不需要提示词注入，不需要越狱模型，也不需要复杂的攻击链。攻击者只要让开发者打开一个仓库就够了。代码以当前用户权限运行，能碰到的是开发机上的源码、令牌、凭据和内部仓库访问权。风险和 Cursor 的 AI 能力本身没关系，是最基础的路径解析问题。

七个月发生了什么：披露流程卡在了哪一步

正常的协调披露该走完确认、复现、修复、通知、公开几步。这次只走到“复现验证”就卡住了。

此后请求更新的邮件、HackerOne 的升级、对 Cursor 高层的直接联系，都没换来实质性回复。

Mindgard 记录到这七个月里 Cursor 发布了 197 个以上的新版本；他们另有统计称，从报告提交到披露之间过去了 70 多个版本。两个数字口径和统计区间不同，Mindgard 没有解释，这里也不做合并。能确定的只有一点：版本一直在更新，这个问题一直没被列进修复清单。

需要说明，目前没有公开信息显示这个漏洞已经被实际利用，也没有 CVE 编号或正式的严重性评级。“零日”“任意代码执行”这些标签，不等于已经发生大规模攻击。

对谁意味着什么：企业安全团队和 Windows 开发者该做什么

企业侧负责终端和供应链的安全负责人，能做的是把工作区目录下的可执行文件按路径拉黑，而不是按哈希——攻击者随时能换个哈希绕过检测。AppLocker、Windows App Control、EDR 都支持路径级限制。代价是要把开发者常用的构建脚本和本地工具链重新过一遍白名单，短期内会增加运维工作量，但比事后处理凭据泄露的成本低。

用 Cursor 在 Windows 上写代码的开发者，眼下最现实的做法是：打开来源不明的仓库前，先放进 Windows Sandbox 或一次性虚拟机。杀毒软件按哈希拦截防不住这类攻击。克隆完不看清仓库结构就直接用 Cursor 打开，现在的风险比几个月前更明确了。

接下来该看的变量很具体：Cursor 会不会发布补丁说明，会不会给出 CVE 编号或正式评级，会不会有独立研究者公开复现。这三项目前都还没有公开信息。