OC 原创示意图。

据安全公司 Mindgard 披露，Windows 版 Cursor 在打开项目时会寻找 Git 可执行文件；如果仓库根目录中被放入一个恶意 git.exe，Cursor 可能在没有点击、确认或警告的情况下自动执行它。

一句话结论： 这不是“AI 被提示注入”那类新奇攻击，而是一个更传统也更直接的信任错误：开发工具把来自不可信仓库的文件，当成了本机可以执行的 Git 程序。

Mindgard 用一个无害的演示复现了问题：把 Windows 计算器重命名为 git.exe 放进仓库，然后用 Cursor 打开项目，计算器便被自动启动，而且会被重复调用。进程日志显示，Cursor 执行的是仓库里的程序，并向它传入了 git rev-parse --show-toplevel。若把计算器换成真正的恶意程序，代码会以当前用户的权限运行。

这个细节决定了风险有多大。攻击者不需要说服 AI 运行脚本，也不需要等开发者点击终端命令；只要让开发者下载并打开一个精心准备的仓库，正常的 Git 探测流程就可能成为触发器。对于经常试用开源项目、面试作业和陌生 Demo 的程序员来说，“只是打开看看”不再等于只读。

OC 原创解释图：漏洞发生在 Git 可执行文件发现阶段，不需要模型参与。

披露时间线也值得单独看。Mindgard 称其在 2025 年 12 月 15 日首次报告漏洞，随后通过邮件和 HackerOne 多次跟进。Cursor 的安全负责人曾解释，最初的自动邀请流程失效；报告后来一度被判定为信息性问题，HackerOne 复现后重新打开。Mindgard 最后一次公开验证是在 2026 年 4 月 30 日，版本为 Cursor 3.2.16。到 7 月公开披露时，研究方称仍未收到修复状态。

这里必须保留证据边界：上述响应过程目前主要来自 Mindgard 的单方记录，Cursor 尚未公开回应这篇披露，也没有发布与之对应的安全公告。因此可以确认的是研究方给出了可复现路径、进程日志和时间线；不能确认的是 Cursor 内部究竟如何定级、是否正在灰度修复，以及所有当前版本是否仍受影响。

Cursor 自己的 安全页面 还有一个容易被忽略的说明：它默认关闭了 VS Code 的 Workspace Trust，并允许用户手动打开。Workspace Trust 能限制不可信目录中的调试、任务和部分工作区设置，但这次问题发生在 Git 程序发现路径，不能在厂商确认前把“打开 Workspace Trust”当成已经修复漏洞。

本站编辑韩启明认为，这条新闻真正暴露的是 AI IDE 的权限模型仍没有跟上使用方式。过去，编辑器默认开发者打开的是自己信任的代码；现在，人们每天让 Agent 克隆陌生仓库、安装依赖、运行测试。仓库从“文档”变成了可能主动影响本机的输入，默认信任就需要重新设计。

在官方补丁和影响范围明确前，Windows 用户最现实的做法是不要直接在主力系统中打开来源不明的仓库。个人可以使用 Windows Sandbox 或一次性虚拟机；企业则可以用 AppLocker、Windows Defender Application Control 或 EDR，阻止工作区目录里的可执行文件被编辑器启动。最重要的一点不是记住 git.exe 这个文件名，而是把陌生仓库当成陌生程序来处理。

参考来源

• Mindgard：Cursor 0day 完整披露：原始研究、复现记录与披露时间线。
• Cursor：Security：用于核对 Cursor 的安全报告渠道及 Workspace Trust 默认设置。
• Visual Studio Code：Workspace Trust：用于说明受限模式能够和不能够保护的范围。
• Visual Studio Code：Source Control FAQ：用于核对编辑器调用 Git 及仓库探测机制。