Cursor 零日摆烂七个月，AI编程工具信任崩塌

等一下。前脚 Cursor 和 SpaceX 签了 600 亿美元的收购协议，后脚三拨安全研究员就把它扒了个底朝天。

这周从周一到今天，三家独立安全团队，Mindgard、Adversa AI、Pillar Security，连续公开了 AI 编程工具的多处严重漏洞。目标不只 Cursor 一家，GitHub Copilot CLI、Gemini CLI、OpenAI Codex 全部中招。唯一一个按规范走完披露流程、发安全公告、打补丁的，是 AWS 的 Kiro。AI 编程的头部玩家们集体选择了沉默。

这不是一次孤立的事件。这是 AI 编程工具安全模型开始露底的时刻。

七个月等来一个「静默修复」

Mindgard 的遭遇最能说明问题。

2025 年 12 月 15 日，Mindgard 发现了一个极其简单的漏洞：Cursor for Windows 加载项目时，会在工作目录中自动搜索 git.exe。攻击者只需在仓库根目录放一个同名的恶意二进制文件，Cursor 会直接执行它，没有弹窗，没有确认，没有任何用户交互。如果项目一直打开，恶意代码会反复执行。

Mindgard 按行业标准流程提交了报告。然后，什么也没发生。

后面七个月的时间线读起来像一出荒诞剧：自动邀请进 HackerOne 的流程「坏了」→被归类为 Informative→申诉后重开→Cursor 确认收到→然后彻底沉默。期间 Cursor 发布了 197 个新版本，没有一个修补这个漏洞。

直到 7 月 14 日，Mindgard 一怒之下全文公开。NVD 隔天就分配了 CVE-2026-63093，CVSS 评分 8.8（High）。

Cursor 的反应尤其耐人寻味：他们赶在 7 月 13 日，Mindgard 公开的前一天，「静默修复」了这个问题。不发安全公告、不分配 CVE、不告诉用户哪个版本修了。到截稿为止，数百万 Cursor 用户仍然不知道自己是否已经升级到了安全版本。

两下点击，你的机器就不是你的了

Mindgard 公开的第二天，Adversa AI 放出了另一个更精妙的攻击链，取名为 DeepJack。

Cursor 安装时会在系统注册 cursor:// 协议处理器，让浏览器链接可以直接启动 IDE 并执行特定操作，打开文件、安装 MCP 服务器等等。Adversa 发现的是经典参数注入漏洞在这个新攻击面上的重现。

攻击者把恶意 cursor://mcp/install URL 做双重 URL 编码，藏进一个看似无害的代码审查链接里。受害者点开「Review this PR」，Cursor 弹出来的却是 MCP 安装确认对话框。

最妙的是这个对话框本身的设计缺陷：命令参数是单行文本框。攻击者用大量空白字符把恶意命令推到屏幕右侧，对话框里只显示无害的程序名。受害者一看「装个计算器」，点下 Install，真正的 payload 开始干活了。

Adversa AI 在 4 月 27 日就拿到了 Cursor 内部的 root cause 确认工单，「单行文本框导致命令溢出视图」，但 Cursor 内部知道了两个月，没有修。到 7 月 15 日，最新版 Cursor 3.9.8 仍然可以复现。

而且 cursor:// 只是冰山一角。Claude Code 注册了 claude-cli://，VS Code 注册了 vscode://，Codex 注册了 codex://，Warp 注册了 warp://，几乎每个主流 AI 编程代理都注册了自定协议处理器，大部分都暴露了高风险路由。

没有谁能独善其身

你可能觉得这只是 Cursor 的问题。并不是。

Cymulate 在 6 月就发现 GitHub Copilot CLI、Gemini CLI 和 OpenAI Codex 存在完全相同的二进制劫持漏洞。GitHub 付了赏金但把严重等级降到 Low；Google 确认了但没有修复时间表；OpenAI 直接关闭报告，理由是「能放 git.exe 的攻击者已经有系统权限了」，这个论证是错的，因为攻击向量恰恰就是克隆仓库这个动作。

Pillar Security 在 7 月 21 日发表了最新研究：漏洞不在沙箱本身，而在于 AI 代理生成的文件会被其他开发工具自动消费。Python 解释器检测、VS Code tasks、Docker 通信，AI 代理能写文件，而其他软件自动执行这些文件，这就构成了一条间接逃逸路径。

唯一按行业标准走完全部流程的是 AWS Kiro。亚马逊分配了 CVE-2026-10591（CVSS 8.8），给研究员打款，在两个星期内修完并发安全公告。AWS 的响应速度让所有头部 AI 公司相形见绌。

为什么这事比看起来严重

开发者的工作站在公司安全模型里一直是个特例：要保持生产力所以权限高，要访问代码和 CI 所以有 SSH key、云凭证和 Token，要协作所以经常克隆外部仓库。

AI 编程工具把这个特例放大了不止十倍。它们被设计成高权限的，能读写文件、执行命令、访问网络，因为「帮我写代码并跑测试」天然就需要这些权限。但安全模型没有跟上：一个确认弹窗就是全部防线。没有代码签名、没有沙箱加固、没有 Mark-of-the-Web 检查。

Adversa AI 首席研究员 Rony Utevsky 说了句大实话：「浏览器和操作系统花了二十年，在确认弹窗后面建起多层防御，代码签名、沙箱、Web 标记。AI 编程工具正在从零重建确认弹窗，然后把它当作全部防线。」

这还不是最坏的。最坏的是当这些工具被攻破时，失陷的不是一台普通电脑，是一个可以直接通往公司 CI/CD、生产服务器和源代码仓库的入口。

眼下你能做什么

没有银弹。但有几件事可以立刻做。

隔离环境跑你的 AI IDE。特别是 Windows 用户，在 Windows Sandbox、WSL 或临时 VM 里打开不明仓库。不要直接在宿主机上跑未经审查的外部项目。

管理 MCP 服务器。企业团队应该通过托管设置做允许列表，只允许经过组织审核的 MCP 服务器。在邮件和 Web 网关阻断 cursor://mcp/install 这类 URI 模式。

关掉不必要的自动执行。Cursor 的 Auto-Run Mode、自动终端执行等功能在不需要时关闭，降低攻击面。

盯住厂商的行为，别只信他们的承诺。安全响应能力应该是评估一个开发工具是否值得信任的关键指标。七个月不理漏洞的公司，不值得你把生产凭证放在它的沙箱旁边。

这周的密集披露不会是终点。更多针对 AI 编程工具的安全研究正在路上，攻击面只会越来越大。AI 编程工具还很新，新到行业还没建立起与之匹配的安全文化。但如果你是每天用这些工具写生产代码的人，你最好先知道门在哪。