MCP 的 STDIO 传输:一个引发 11 个 CVE、暴露 20 万个代理的设计决定

这是什么?

2026 年 4 月 16 日,OX Security 发布了《The Mother of All AI Supply Chains》,协调披露 Model Context Protocol(MCP) 中的一个系统性漏洞。MCP 是 Anthropic 于 2024 年推出的开放标准,用于让大语言模型与外部工具通信。该缺陷并不存在于某个孤立的实现,而是位于 STDIO 传输本身 —— MCP 用于将代理连接到本地工具的默认机制:MCP 服务器配置中的 command 字段会被原样传给 subprocess 并在宿主机上执行,既无校验,也无任何清理,配置与命令之间不存在执行边界。

OX 对生态进行了扫描,发现大约 7,000 台启用 STDIO 传输的公网可访问 MCP 服务器。按此比例外推,研究人员估计在自托管部署中存在 约 20 万个易受攻击的实例,受影响的软件供应链下载量超过 1.5 亿次。该披露当天即被《The Register》转载,4 月下旬被 VentureBeat 与《The Hacker News》报道,Cloud Security Alliance 也于 2026 年 4 月 23 日 发布研究简报跟进。Anthropic 确认了这一行为,拒绝修改协议,并将 STDIO 执行描述为「安全的默认值」,把输入清理的责任交给开发者。

在此后的六周里,该缺陷已经在下游框架中派生出 至少十一个 CVE,包括 LiteLLM 的 CVE-2026-30623,以及 LangFlow、Flowise、LangChain 和 Cursor 的相关公告。

它是如何工作的

MCP 的 STDIO 传输只是 subprocess 的一层薄包装。代理读取包含 command 字段的服务器配置,把它交给 StdioServerParameters,然后启动指定的进程,通过标准输入输出交换 JSON-RPC 消息。其约定是「该命令必须是受信任的启动器」;但在实际链路中,所有上游环节都把这一字段当作普通数据处理。

# 概念结构 —— 仅作说明,并非可用 exploit。
# 来源:OX Security advisory,CSA 研究简报。

# 代理读取的 MCP 服务器配置:
#   transport: "stdio"
#   command:   "<由攻击者控制的字符串>"
#   args:      [...]
#
# 在每个官方 SDK(Python / TypeScript / Java / Rust)中
# 都会到达 StdioServerParameters,并在代理宿主机上作为
# 子进程启动。无白名单、无 shell 转义、默认无沙箱。

OX 在该原语之上识别出四类利用方式。第一类是 通过框架的 Web 界面进行未授权命令注入:LangFlow 与 LiteLLM 都暴露了创建 MCP 服务器的接口,其中 command 值原样到达 STDIO 启动器。第二类是 白名单绕过:试图将 command 限制为已知启动器的框架(Flowise、Upsonic)所提供的白名单,可以通过绝对路径、参数夹带或备用解释器绕过。第三类是 通过 MCP 仓库分发恶意包:OX 向 11 个 MCP 仓库提交了一个良性概念验证包,其中 9 个未做任何安全审查便接受,这意味着攻击者可以发布一个 command 本身就具有恶意性质的服务器。第四类是 配置篡改:任何有权向多租户网关添加 MCP 服务器的用户,实质上都能以网关进程身份执行代码。

关键在于,以上路径都不需要破坏协议本身。STDIO 传输完全按照文档运行;真正的攻击面来自「开发者会清理自己的配置」这一假设与现实部署之间的差距。

这为何重要

MCP 的 STDIO 问题是当前 LLM 安全领域最清晰的一个 协议与产品 之争的公开案例。Anthropic 的立场 —— STDIO 是一种传输,不是权限边界;由开发者负责所执行的命令 —— 在协议层面是站得住脚的。然而,OX 在生产部署中记录到的下游现实是,数十万套安装直接采用了文档中的默认行为,并将其构建进了对外暴露的基础设施。

目前已能看到三项后果。其一,同一个原语在持续产生 CVE。任何封装 MCP 并在 command 字段附近接受用户输入的框架,距离一次远程命令执行只有一条配置路径,到年底之前预计还会有更多条目加入清单。其二,MCP 仓库如今已成为一条可信的供应链攻击路径:攻击者不再需要入侵开发者的机器,只需向某个审核宽松的仓库提交一个软件包,就能把代码送进对方的代理。其三,协议方的回应树立了一个先例:发布一个开箱即提供任意命令执行能力的默认行为,并将安全使用的全部责任压给每一个实现者,这是近年来其他任何传输标准都未曾这样做过的姿态。

对于今天在自托管运行代理框架的团队而言,实际含义是:MCP 服务器配置就是攻击面的一部分,必须像代码一样对待。

防御措施

没有一个统一补丁可装。缓解措施分布在四个层面,所有层面都可以在不等待 Anthropic 的情况下落地。

第一层是 命令白名单,可参照 LiteLLM 的 MCP_STDIO_ALLOWED_COMMANDS(在 v1.83.6-nightly 引入,v1.83.7 稳定)。允许集应是您的环境真正需要的、最小一组已知启动器 —— 例如 npx、uvx、python、python3、node、docker、deno —— 而该检查必须拒绝绝对路径、参数夹带与间接解释器。白名单的显性效果是显然的,它的隐性收益是每次请求新增条目时都会强制一次代码评审。

第二层是 进程隔离。MCP 服务器应运行在沙箱中:不挂载宿主文件系统的容器、非特权用户、syscall 过滤、除非明确需要否则禁用出网,并且使用与代理网关不同的身份。即使被启动的命令确实是恶意的,影响面也会坍缩在沙箱内。

第三层是 仓库治理。请像对待 npm 或 PyPI 那样对待 MCP 包仓库:锁定版本,优先使用已签名的包,生产环境维护内部镜像,在安装前审阅 command 与 args 字段,并且永远不要让生产网关上的 MCP 服务器包自动更新。

第四层是 网络与访问控制。MCP 网关、n8n 实例、LangFlow 看板以及类似工具不应在无认证的情况下暴露在公网。请将其置于 VPN 或带认证的反向代理之后,记录每一次 MCP 工具调用以及发起者的身份,并对任何 MCP 服务器配置变更触发告警。

另一项成本较低的措施是 跟踪整条 CVE 级联。已发布的十一条 CVE 共享同一个根因;您所依赖的、任何封装 MCP 的框架都是下一个候选目标。请订阅 OX Security 的 advisory、CSA Labs 的研究简报,以及受影响供应商的官方公告。

状态汇总

项目	出处	日期	说明
OX Security 首次披露	《The Mother of All AI Supply Chains》	2026-04-16	约 7,000 台公网服务器,外推约 20 万
媒体报道	《The Register》	2026-04-16	报道 Anthropic「by design」立场
级联综述	《The Hacker News》	2026-04	「Anthropic MCP Design Vulnerability Enables RCE」
研究简报	Cloud Security Alliance Labs	2026-04-23	系统性供应链视角
LiteLLM 通告	CVE-2026-30623	2026-04	已在 v1.83.7-stable 修复;新增白名单
扩展通告	OX Security 后续	2026-05	编目 11 个 CVE,四类利用方式
Anthropic 立场	MCP 规范维护方	2026-04	不计划修改协议

MCP 的 STDIO 传输,如今已成为「能挺过每一次单点修复」的设计决定的公共范例。请把配置字段当作不可信代码,而非数据 —— 并默认级联尚未结束。