七个月。七十多个版本更新。一个只要打开项目文件夹就能触发的远程代码执行漏洞，至今敞着口。这不是某个上古遗留系统的陈年病灶，这是当下最炙手可热的 AI 编程工具——Cursor，在 2025 年 12 月仍然存在的现实。
不用点任何东西，打开仓库就中招
触发条件荒谬到像个玩笑
漏洞本身简单得令人不安。安全公司 Mindgard 的研究人员发现，当 Cursor IDE 在 Windows 上加载一个项目时，它会在多个位置自动搜索 git.exe，其中就包括当前打开的工作区目录。如果仓库里恰好躺着一个名叫 git.exe 的恶意可执行文件，Cursor 会毫不犹豫地运行它——没有安全警告，没有确认对话框，甚至不需要你打开终端。你只是在一个受信任的 IDE 里点开了“打开文件夹”，攻击者就已经拿到了你机器的控制权。
这不是 Git 的问题，是设计理念的缺口
很多人第一反应是“谁会从不明来源克隆仓库”。但别忘了，现代开发工作流里，从内部 GitLab、同事的 PR 分支、客户发来的示例代码拉取项目是日常操作。任何一个被入侵的仓库，任何一次社工攻击，都可以轻易把恶意 git.exe 送到你面前。而 Cursor 的信条是“帮你更快写代码”——它默认工作区的文件是可信的，这个假设在 2025 年的威胁模型面前，脆弱得像层纸。
报告、确认、然后石沉大海
Mindgard 七个月的马拉松式沟通
Mindgard 并不是一夜之间就选择了完全披露。他们早在 2025 年 5 月就首次向 Cursor 的安全团队报告了这个漏洞，之后七个月里多次跟进。Cursor 的首席信息安全官（CISO）一度确认了问题的严重性，但接下来发生的事情更令人沮丧：内部自动化流程出了故障，工单系统把安全报告的优先级“吞掉”了，后续版本的发布计划里，修复补丁消失得无影无踪。一边是持续输出的新功能、新模型集成，一边是一个可以被脚本小子利用的 RCE 漏洞，优先级排序出现了根本性的扭曲。
70 多个版本，没有一个修过这个洞
在漏洞存续期间，Cursor 发布了超过 70 个新版本——功能迭代之快，恰是这款 AI IDE 吸引开发者的理由之一。但这 70 多次发布里，没有一次包含对这个 0day 的修复。Mindgard 等到的只有沉默和流程断档。最终，完全披露成了保护用户的唯一手段。安全行业有一条不成文的规矩：当厂商持续无回应，公开漏洞细节不是攻击，而是止损。12 月 15 日，他们把技术细节摆上了台面，让数百万 Cursor 用户至少知道自己暴露在什么风险里。
问题比一个 git.exe 更深
AI 工具的供应链信任正在被透支
这个漏洞真正刺痛的，是开发者对 AI 编码工具的底层信任。我们允许这些工具访问文件系统、读取环境变量、执行 shell 命令，是因为默认它们会在安全的框架内运行。可当一款 IDE 把工作区里的可执行文件当作合法依赖直接拉起，那“信任”的边界就已经消失了。更糟糕的是，这并非孤例。AI 助手在本地运行任意命令的权限模型，MCP 插件对环境的访问粒度，代理式编码工具自动修改文件时的审计缺失——整个生态都在狂奔，而安全护栏迟迟未到。
为什么“全自动”在这里变成了弱点
Cursor 的设计哲学是减少摩擦。它希望你打开项目后立刻开始工作，所以自动探测 Git、自动为你准备好版本控制的上下文。这种自动化在正常情况下是优雅的，但当探测路径包括工作区根目录时，优雅就变成了危险。问题不在于某个工程师犯了错，而在于整个产品设计中没有植入“工作区不可信”这一微隔离概念。零信任架构说了这么多年，到了开发者工具这里，一遇到可用性压力，又被打回原形。
现在能做什么
马上动手的临时防线
在官方补丁落地之前，有几个动作可以大幅降低被攻击面。最直接的是用 Windows 内置的 AppLocker 或软件限制策略，阻止从你常规存放代码的工作区目录里执行名为 git.exe 的文件。如果公司有端点安全产品，可以下发自定义规则拦截这一类行为。对于来源不可信的仓库——同事发来的压缩包、网上下载的示例项目、第三方审计的代码——一律在隔离虚拟机或沙箱里打开。这听起来像个上世纪九十年代的安全建议，但面对一个七个月没修的 0day，老办法就是好办法。
团队层面的工作流审视
更深一层，技术管理者应该把这次事件当成一个契机，重新审视团队使用 AI 编码工具的权限模型。哪些工具可以访问本地文件系统？哪些可以执行 shell 命令？这些能力是默认开启的吗？你的 CI/CD 管道里会不会有开发者无意中引入了包含恶意文件的依赖？安全不只是加固产品本身，也是持续矫正工具链里的每一个默认信任假设。如果你在用 Cursor，立刻通知你的开发团队，更新安全意识，直到那个姗姗来迟的补丁真正生效。
