opencode 补上 MCP 登录环节的远程执行漏洞却没发公告：恶意服务器被划出威胁模型，扫描器就看不见

远程 MCP 服务器算不算攻击方，成了编程智能体厂商发不发安全公告的分界线：opencode 在 9 月修掉了一个连上远程 MCP 服务器就可能被执行命令的漏洞，但修复以「重构」的名义发出，没有安全公告，也没有 CVE。

先给结论：这件事里最该记住的不是漏洞本身，也不是修得快不快，而是厂商的划法。按披露方的说法，开发方 Anomaly 认为恶意 MCP 服务器不在自己的威胁模型里；只要这条线不动，同一类问题修了也不会出现在企业的漏洞扫描和依赖告警里，谁在用旧版本，只能自己去查。

一件具体的事：给智能体接一个远程工具

设想一位用 Windows 的开发者，在 opencode 的配置里加了一个远程 MCP 服务器，好让编程智能体能读公司的工单系统。第一次连接时，服务器回答「需要登录」，opencode 自动打开浏览器，把人送到登录页。这一步本来就是为了省事：不用复制粘贴网址，点一下就登。

据 Pillar Security 的披露，问题就出在「自动打开浏览器」这一步。登录页的地址（OAuth 发现文档里的 authorization_endpoint 字段）是由被连接的服务器自己填写的；在 1.18.32 及更早版本里，这个字符串没有经过来源比对，一路传给打开浏览器的 open 依赖包，而这个包在 Windows 上会把网址拼进一条 PowerShell 命令。Pillar 给出的利用方式是一个看起来完全正常的 https 地址，里面夹带 PowerShell 的子表达式，命令会在浏览器打开之前就被执行。整个过程不需要用户再点任何东西，也不需要诱骗模型。

受影响范围按 Pillar 的说法是 1.0.137 到 1.18.32、运行在 Windows 或 WSL 上的 opencode；macOS 与 Linux 上的打开方式不经过命令行，不受影响。Pillar 还写到一个容易被低估的细节：服务器在被加入配置时不必是恶意的，载荷是在连接时随响应一起到达的，所以日后被入侵、域名过期或被抢注，都能触发同一条路径。

厂商那边能核对到什么

我们逐条打开了 opencode 仓库里的公开记录，能核对到的有三件事。

第一，修复确实存在。PR #51414 于 9 月 25 日合并，标题是「refactor(core): share a browser opener across opencode and tui」。说明里写的是把八处直接调用 open 的地方收拢成一个模块；新模块只放行 http 与 https，MCP 登录的 redirectToAuthorization 也加了同样的检查，open 从 10.1.2 升到 11.0.4。说明里没有出现「安全」或「漏洞」字样。

第二，发布说明同样没提。据 v1.18.33 的发布说明（9 月 28 日发布），与此相关的只有一句：MCP 打开浏览器失败时，现在会在启动器立即退出的情况下报告出来。

第三，这家公司并不是不发公告。opencode 的安全公告列表里能看到三份公开公告，其中一份高危公告发布于 9 月 24 日，正是这个修复合并的前一天；另外两份发布于 1 月。所以缺的不是流程，而是这一次没有走这个流程。

至于「为什么没发」，我们只能看到 Pillar 的转述：Anomaly 回复说，处理恶意 MCP 服务器不在其威胁模型之内。我们没有找到 Anomaly 对此的公开表态。

为什么重要

这类漏洞不是新问题。据 NVD 的 CVE-2025-6514 记录，2025 年 7 月公布的 mcp-remote 漏洞描述就是：连接不可信的 MCP 服务器时，authorization_endpoint 响应里构造的地址会导致操作系统命令注入，JFrog 给出的 CVSS 评分是 9.6。Pillar 另外列出 2025 年夏天同一位置的两个 CVE。同一个字段、同一种后果，一年多以后又出现在一个据 Pillar 统计每周约 300 万次 npm 下载的编程智能体里。

区别在于记录方式。CVE-2025-6514 进了 NVD，企业的扫描器能对上号；opencode 这次没有编号，依赖告警不会响。Pillar 的原话是，这个漏洞「在 diff 里完全公开，在防守方通常会看的地方完全看不见」。

分析推断：编程智能体会越来越多地连接远程 MCP 服务器，如果厂商普遍把「服务器本身是恶意的」划在威胁模型之外，这一类登录、发现文档、元数据环节的修复就会大量以普通更新的形式发出，企业的漏洞管理会系统性地漏掉它们（依据：本案 PR 与发布说明的写法，以及 Pillar 转述的厂商立场；目前只有这一个案例，不能说明行业已经普遍如此）。

还有一层是「人在哪里接手」。在这个流程里，唯一的人工决定发生在把服务器写进配置的那一刻；之后的登录跳转、地址解析都是自动的。Pillar 的建议也落在这里：升级到 1.18.33 以上，暂时升不了的 Windows 与 WSL 用户先移除没有审查过的远程 MCP 服务器。它还指出，只校验 http 与 https 并不够，真正堵住这条路径的是 open 升级后对 PowerShell 参数的转义，更根本的做法是不把远程字符串拼进命令行。

最强反方

最有力的反驳是：Anomaly 修得又快又彻底，没有 CVE 不等于用户没被保护。从 PR #51414 看，修复分了三层，依赖升级、统一的打开函数、登录边界上的检查，按 PR 的内容，9 月 28 日之后升级的用户已不受这条路径影响；反方还可以说，opencode 更新频繁，多数人可能早已在新版本上（这一点没有公开数据）。况且「恶意服务器不在威胁模型内」并非没有道理，用户主动连接的服务器本来就被授予了很大的信任；Pillar 文中也承认，open 包的说明早就写明不对不可信输入做安全保证，就像没有人为 exec 函数执行了传入的命令去申请 CVE。

我们在这里让一步：对个人用户，修复是否带编号影响确实有限，按时升级就够了。但我们仍然坚持论点，原因在企业一侧：企业的盘点依赖编号与公告，固定版本的内部镜像、CI 环境和离线安装不会因为「多数人已升级」而自动更新；而且 Pillar 写到，服务器在加入配置时可以是可信的，事后才变质，这正是「用户已经信任它」这一理由覆盖不到的情形。Pillar 自己出售 MCP 与智能体安全产品，有放大问题的动机，所以我们只采用了能在 opencode 仓库里核对到的部分作为事实依据。

我们不知道什么

• 有没有人在真实环境中利用过这个漏洞。Pillar 没有提到在野利用，我们也没有找到相关报告。
• Anomaly 是否会补发公告或申请 CVE；目前我们只看到 Pillar 转述的厂商立场，没有厂商自己的公开说明。
• 仍在使用受影响版本的 Windows 与 WSL 装机量有多少，没有公开数字。
• Pillar 页面标注的日期是 10 月 19 日，但文末时间线写的是 10 月 4 日发布报告，两者不一致，我们无法确认首次公开的时间。
• Pillar 对 Claude Code、gemini-cli 等其他客户端「做法正确」的评价来自其自己的代码审查，我们没有逐一核对。

接下来看什么

一是 opencode 的安全公告列表里会不会出现这一条；二是其他编程智能体厂商在披露类似问题时，会不会把「远程 MCP 服务器是恶意的」明确写进或写出自己的威胁模型；三是 MCP 官方 SDK 对登录地址的校验策略会不会从三个协议的黑名单收紧。