一个缺陷，五家机构：走廊问题终于有了名字

本文引证来源 · Ars Technica 安全报道，2026年10月5日，经转载方 Times of AI 逐字转引 · 研究更新框架与信任链分析经 Pangolinfo（逐字转引） · IETF 互联网草案 draft-mohiuddin-mcp-security-considerations-00（提及） · MCPInspect 研究，DSN 2026（提及）。本文对独立研究者按工作引用、不落姓名；机构作为报道事实保留。

五家互不相关的机构——一家搜索巨头、一家全球性银行、一家向量数据库公司、一个国家级数字主管机构、一个市政府——确认并修复了同一个协议里的同一个缺陷。这句话就是全部故事。「Model Context Protocol（MCP）服务器中的同一缺陷，已被 Google、摩根大通、Weaviate、法国部际数字主管机构和印尼唐格朗市政府的安全团队分别确认——并修复，」十月的研究总结如此记录；两枚 CVE 已经发布，发现横跨五个月的独立工作。最严重的案例评分 10 分制下的 8 分：「Google 的数据库 MCP 工具箱初始化 HTTP 客户端时，既没有重定向策略，也不校验目标 IP 地址。」

一、模式有了名字，现在还有了草案

这项发现的提出者——本文按工作引用、不落姓名——把五个月的案例归纳进一份 IETF 互联网草案（draft-mohiuddin-mcp-security-considerations-00），在同一个术语下收拢六类漏洞：协议跳转（protocol pivoting）。攻击者从模型面向的协议进来，转向服务器在背后能触及的一切。中继是整个攻击的心脏，用 Rapid7 漏洞情报主管对 Ars Technica 的原话说：「有人把文本埋进内容里，代理读了它，然后把它当作一次普通的委派任务转交给另一个代理——第二个代理执行了它，因为它信任交活的人。链条上的每一环都完全按设计行事，这正是它难以察觉的原因。每个协议都假设自己独立存在，所以每个协议都检查自家正门，而门与门之间的走廊无人看守。」

最后那句话值得活得比新闻周期更长。它对多代理系统的拼装方式给出了精确诊断：不是粗心，而是模块化——每个协议只规定自己的边界、检查自己的门，把连接各家的走廊留给「别人」。规模一大，所有人的问题就成了没人的问题。

二、为什么这是结构性的，不是偶然的

根因假设，按分析记录的表述：跨过协议边界的数据之所以可信，是因为它来自系统内部。五家互不隶属的机构在互不知情的情况下做了同一个决定——这恰恰说明它不是 bug 模式，而是架构默认值。规模可以度量：在 DSN 2026 上发表的 MCPInspect 研究做了一个集成前扫描器，发现 「833 个存在漏洞的 MCP 服务器——其中 18 个的工具描述可疑或具有误导性，提示存在供应链层面蓄意污染代理行为的企图」。而美国联邦层面的发现还开着口子：「美国联邦 MCP 服务器中的五个发现仍未修复。」

Google 的修法最有教学意义，因为它演示了边界本来该在哪：一段 IP 段允许清单加黑名单，在启动时就拒绝不安全的基准 URL，而不是等第一个请求上门。把检查提前，把它绑到配置上而不是绑到请求的运气上——这就是补丁和边界之间的差别。

三、设计决定爆炸半径——然后让验证封住每一跳

防御指南在没人提问之前就汇合了：协议自己的安全最佳实践与国家级机构指南都指向纵深防御、最小权限，以及明确拆分只读与写入工具。真正站得住的表述很直白：「爆炸半径是一个设计决定。补丁堵住今天的洞；工具设计决定下一个洞让你付出什么。」只读工具的最坏情况是一个错误答案；写入工具的最坏情况是一个被清空的账户。但同一份分析也诚实地划出了这种方法的顶：「被攻陷的上游仍然可以返回假数据，任何服务器端设计都修不了这个——只有带外验证可以。」

带外验证，恰好是我们双柱住的地方。RTTP（rttp://）给走廊一层派生而非注册的命名——于是委派任务里写着谁发的，是算术而不是一次由上游控制查询。 IQA（iqa://）让每一跳携带签名声明与新鲜度租约，由下游代理离线验证——信任不跨跳传播，信任在每一跳重新建立，否则这一跳坏输入即拒绝。我们不假装证明能阻止跳转：被攻陷的代理照样能签名。它改变的是经济学——每一跳都留下第三方事后可查的证据，走廊不再是整栋大楼里唯一不装监控的房间。

五家机构打了补丁。草案给模式起了名字。走廊依旧没有灯——但这是第一次，它有了地址，而有地址的东西才能被审计。