打开一个 Git 仓库 Cursor 就自动执行了恶意代码
想象一下这个场景：你在 GitHub 上发现一个感兴趣的开源项目，顺手 git clone 下来，用 Cursor 打开准备看看代码。
就在你打开仓库的那一瞬间，恶意代码已经在你的电脑上悄悄运行了。
没有弹窗，没有提示，没有任何确认按钮。你甚至还没来得及敲一行代码，攻击者已经拿到了你系统的控制权。
这不是科幻小说。这是安全公司 Mindgard 在 2025 年 12 月发现的一个真实的 Cursor 0day 漏洞——而且 7 个月过去了，至今仍未修复。
一个"简单到令人不安"的漏洞
这个漏洞的原理，用一句话就能说清楚：
Cursor 在加载项目时，会在多个位置搜索 Git 可执行文件。而其中一个搜索位置，正是当前工作区的根目录。
也就是说，如果攻击者在仓库根目录放了一个名叫 git.exe 的恶意程序， Cursor 就会在打开项目时自动执行它。
Mindgard 的研究员用一个最简单的实验证明了这一点：他们把 Windows 自带的计算器程序改名为 git.exe，放进仓库根目录。然后，只要用 Cursor 打开这个仓库——计算器就弹出来了。
更可怕的是，这不仅仅是一次性的触发。研究员发现，只要项目保持打开状态，Cursor 会在正常操作过程中反复执行这个二进制文件。屏幕上的计算器窗口越来越多，而这一切都没有任何用户交互。
在真实攻击中，计算器当然可以被替换成任意恶意代码——木马、勒索软件、窃密程序。攻击者获得的是当前用户权限下的任意代码执行能力。
7 个月， 70 多个版本，零响应
漏洞本身或许"简单"，但更令人震惊的是漏洞披露之后发生的事情。
2025 年 12 月 15 日， Mindgard 首次发现该漏洞，当天就通过 Cursor 官方安全邮箱提交了报告。
然后，石沉大海。
没有确认收到。没有回复。时隔两周后，研究员又发了一封跟进邮件——依然没有任何回应。
到了 2026 年 1 月 13 日，研究员不得不在 LinkedIn 上公开发帖，请求有人帮忙联系 Cursor 的安全团队。终于，在评论区有人 @了 Cursor 的 CISO 之后，对方才首次回应——承认是内部自动化流程出了问题，未能触发 HackerOne 的漏洞提交邀请。
漏洞随后被重新提交到 HackerOne 的私有赏金计划。但令 Mindgard 震惊的是——报告最初被以"Informative"和"超出范围"为由关闭了。
经过据理力争之后， HackerOne 重新打开了报告，复现了问题，并确认已交付给 Cursor。然后……一切再次归于沉寂。
从 1 月到 7 月， Mindgard 多次请求进度更新，没有任何回复。向 HackerOne 升级，没有结果。直接联系 Cursor 高层——同样石沉大海。
将近 210 天的时间里，超过 70 个新版本被发布， 197+个版本迭代过去了。而漏洞依然存在，用户依然暴露在风险之中。
当创新不再倾听
这个问题最后指向了一个更令人不安的问题：
Cursor 目前拥有 700 万+活跃用户， 100 万+日活， 100 万+付费用户，被超过 5 万家公司在使用，估值高达 600 亿美元。这样一家公司，连一个如此直截了当的任意代码执行漏洞都修不了吗？
Mindgard 在博客中尖锐地提出了几个可能的原因：
- 现代漏洞赏金计划是否已经不堪重负？
- AI 产品的安全漏洞数量正在激增，传统的漏洞分类和处理流程是否正在崩坏？
- Cursor 是否因为忙于商业扩张和收购谈判，而把用户安全排到了次要位置？
无论真正的原因是什么，结果是一样的：用户正在使用一个已知存在严重漏洞的软件，而厂商选择了沉默。
这让安全研究者面临一个艰难的道德抉择：继续保持沉默，让用户在虚假的安全感下继续使用？还是公开披露漏洞，让用户至少能够做出知情决策？
Mindgard 选择了后者。
开发者现在应该怎么做
在 Cursor 正式修复漏洞之前，开发者需要自己采取措施来防护。以下是 Mindgard 给出的建议：
企业/受管理的 Windows 系统：
使用 AppLocker 或 Windows App Control 策略，在开发者工作区目录中阻止来自仓库根目录的可执行文件运行。优先使用路径规则（如 %USERPROFILE%\source\repos\*\git.exe）而非哈希规则——因为攻击者可以轻易替换不同哈希值的恶意文件。
Windows 本身不支持"阻止特定父进程启动的子进程"这种精细控制，如果需要更高级的防护，需要借助 EDR 或自定义终端安全产品。
个人开发者：在使用 Cursor 打开不信任的仓库时，务必使用隔离虚拟机、Windows Sandbox 或其他一次性环境。 不要依赖文件哈希黑名单来防御这类攻击——攻击者随时可以更换恶意文件。
更根本的建议是：对任何从网上克隆下来的代码仓库，先用安全工具扫描，确认没有未知的可执行文件后，再用 IDE 打开。
信任需要被赢得，而非被假设
这件事之所以值得每一位开发者关注，不仅仅因为一个具体的漏洞。
真正需要反思的，是 AI 开发工具与我们之间的关系。
AI 编程助手正在被赋予越来越多的权限——访问你的代码仓库、读取你的终端历史、连接你的密钥和凭证、甚至代表你执行命令。这些工具承诺提升生产力，我们也就习惯了给予信任。
但信任不应该是默认的。信任应该通过行为来赢得。
这种"行为"，恰恰体现在一个公司如何回应安全报告、如何与受影响用户沟通、如何对待修复优先级上。
当一个直截了当的漏洞七个月没有得到修复，当研究者的多次请求没有得到实质性回应，用户就有理由重新审视这份信任。
Mindgard 在公告的最后说了一段令人印象深刻的话：
"用户安全必须放在第一位，即使披露让人不舒服。——尤其是当披露让人不舒服的时候。"
这句话，值得所有在 AI 浪潮中狂奔的科技公司，仔细想想。
封面高亮关键词: Cursor 0day 漏洞, 任意代码执行