同一个 SSRF 漏洞，谷歌、摩根大通、法国政府各中一枪：MCP 的结构性安全危机

五起确认，一个假说：先看时间线

2026 年 5 月，独立安全研究者 Syed Anas Mohiuddin 公开了一个判断：在 Model Context Protocol（MCP）服务器里发现的服务端请求伪造（SSRF）漏洞，不是某家公司写错了代码，而是一种结构性缺陷。他给这种攻击范式起了个名字：Protocol Pivoting，协议转向。当时他手里只有一个扎实的例子，外加一个论证。

四个月后，这个假说收到了五份互不相关的验证。谷歌、摩根大通、Weaviate、法国政府数字化部委间司（DINUM）、印度尼西亚 Tangerang 市政府——五个行业的五支安全团队，各自独立确认并修复了同一个 SSRF 漏洞。它们之间不共享代码、不共享老板，唯一的共同点就是都实现了 MCP 协议。

时间线值得逐条摆出来。2026 年 7 月 3 日，CVE-2026-14540 被预留，7 月 31 日正式公布，CVSS 8.0——这是谷歌的 MCP Toolbox for Databases（googleapis/mcp-toolbox）中招，Mohiuddin 被记为发现者。8 月 25 日，Weaviate 把他的名字写进公开安全名人堂。9 月 4 日，法国 data.gouv.fr 官方 MCP 服务器的加固 PR #126 合并。9 月 2 日他向 Tangerang 市政府报告漏洞，9 月 3 日 GitHub 安全公告 GHSA-pw2j-pj4h-f5vg 就发布了，评级 high，从报告到公告只用了一天。摩根大通的责任披露团队确认了他的发现（中危），修复已上线，他的名字出现在摩根大通公开的致谢页面上。此外，安全厂商 Rapid7 还为一个相关但不同的问题发布了 CVE-2026-97228（CVSS 2.7，低危）。

这就是这条新闻罕见的地方。CVE 每天都有，但同一个"错误"在超算厂商、全球银行、开源数据库公司、一个国家政府和一个城市政府身上各出现一次，且都被各自的安全团队独立确认——这种复现密度，在漏洞研究里极不寻常。它说明 Mohiuddin 五月的判断是对的：漏洞不在实现，而在协议设计本身。

Protocol Pivoting 到底是什么？用大白话讲清

MCP 是 AI 编程 Agent 调用外部工具的事实标准：Agent 想查数据库、调 API、读写文件，都通过 MCP 服务器暴露的"工具"来完成。Protocol Pivoting 描述的是攻击者如何借用这套"委托语义"跨越信任边界。它包含两种失效模式，理解了这两种，就理解了全部五起案例。

第一种是 SSRF。MCP 服务器把工具暴露给 Agent，Agent 调用时传入参数，其中一些参数是 URL、路径或接口地址。如果服务器拿着这个值直接去发对外请求，而不检查它实际解析到哪里，那么"服务器的网络身份在跟谁说话"就由 Agent 决定了。而 Agent 会读取不可信的内容并照着行动——网页、文档、工具返回的文本里藏一句精心构造的指令，Agent 就会把它当成参数传进去。换句话说，Agent 成了一个传声筒：任何能把文字摆到 Agent 面前的人，都能间接操控服务器的出站请求。

最经典的落点是云元数据服务。Mohiuddin 五月最初的例子是微软的 playwright-mcp：它的 browser_navigate 工具接受 Agent 传来的任意 URL，完全没有 SSRF 防护，Agent 可以被引向 169.254.169.254——云实例的元数据地址，里面躺着临时凭证。五起新案例里，Tangerang 市政府的 Wazuh-MCP-Server 就栽在同一个地址上：它的 blueteam_check_webshell 工具号称有 SSRF 防护，但防护只拒绝字面 IP 地址，从不解析域名。任何指向内网、回环或链路本地地址的域名都能穿过去，云元数据地址自然也包括在内。

第二种失效模式更隐蔽：对上游数据的不安全处理，最典型的是日志。美国联邦政府那五台尚未修复的 MCP 服务器就属于这一类——以退伍军人事务部（VA）的福利申请服务器为例，上游福利 API 返回错误时，服务器会把完整的上游响应体以 ERROR 级别写进日志，不做任何脱敏。这些响应体里可能包含退伍军人的姓名、社保号、出生日期和住址。注意，不需要任何人攻击，日常的校验失败就足以触发，真实部署环境里每天都会产生这样的日志条目。

两种模式背后是同一个假设：开发者把跨过 MCP 边界的数据——无论是进来的参数还是回来的响应——都当成可信的，因为"它来自系统内部"。在智能体流水线里，这个假设不成立。Mohiuddin 把这句话称为整篇论文的论点，其余全是证据。

还有一层更值得警惕的含义。真实的 Agent 部署是协议链：MCP 管工具调用，A2A 管 Agent 之间的委托，还有负责服务发现的 ANP 等协议。攻击者可以在 MCP 工具返回的内容里藏一段"长得像 A2A 任务指令"的文本，编排 Agent 读到后，会在正常委托流程中把它交给子 Agent；子 Agent 信任自己的编排者，就会执行这条指令。如果那个子 Agent 手里正好有一个带 SSRF 的 MCP 服务器，这次请求就从信任边界内部发出了——带着子 Agent 的网络位置和权限。链条上没有任何一个组件被"攻破"，每个组件都按设计行事，边界就是这样被跨过去的。这才是 Protocol Pivoting 这个名字的由来：转向的不是数据包，而是协议之间的信任关系。

MCP 协议架构示意图

为什么这是协议的病，不是实现者的错

最有说服力的证据恰恰来自"没人犯明显错误"的案例。摩根大通的 jpmorgan-payments/ai 仓库里有一个文档搜索 MCP 服务器，read_documentation 工具在抓取前会做域名白名单检查，它的兄弟工具 related() 却直接拿调用者给的 URL 去服务端抓取，毫无限制。这个组件是从 AWS 的一个开源项目 fork 来的。Mohiuddin 把两个版本并排 diff 了一下：AWS 的原版根本不解引用调用者传来的 URL；摩根大通重写时加了抓取功能，却漏掉了白名单。两支都称职的团队，一次常规的 fork，产生了一个原本两个代码库都没有的洞。

这个案例说明了三件事。第一，漏洞的产生不需要粗心，只需要一次普通的工程动作。第二，扫描器抓不到它——没有任何依赖包是有漏洞的，调用图在传输边界就断了。第三，发现它靠的不是工具，而是把两个版本并排放在一起读代码的人。Mohiuddin 自己也承认，他为此写了个开源扫描器 mcp-safeguard（已发布到 PyPI，覆盖 SSRF、过度权限、提示注入面、信息泄露、认证缺口、生命周期绕过六类），但模式匹配工具会漏掉这类问题中的很大一部分，包括他自己的工具。

往深一层看，根子在 MCP 协议的设计取舍上。MCP 让"把一个函数暴露给 Agent"变得极其容易，但整条路径上没有任何一个环节会促使开发者停下来问：这个参数到底是谁控制的？返回的数据又会流向哪里？协议规范本身没有任何强制性的安全要求，Agent 之间默认互信，委托语义默认传递信任。传统的软件成分分析（SCA）和依赖扫描看的是已知漏洞包和代码内的调用图，可危险的输入根本不走它们建模的代码路径——它走传输层，以"模型选定的工具参数"的形式进来，由扫描器从不读取的工具清单（tool manifest）描述。谷歌工具箱里缺失的重定向策略、摩根大通 fork 里漏掉的白名单、联邦服务器里全量写入的日志，全都是依赖扫描会放行的代码。漏洞不在某个包里，而在服务器对待"我不该信任的输入"的方式里。

这就解释了为什么是五家、为什么互不相关：它们踩的不是同一个 bug，而是同一个"默认"。协议给了所有人同一套默认配置，而这套默认配置里没有安全。

五家修复方案对比：同一个漏洞，五种打法

好消息是，修复本身并不复杂，难的是意识到要修。把五家的修复并排看，能看出一条从"最小可用"到"标杆"的光谱。

谷歌的 PR #3448 是 Mohiuddin 点名推荐的参考实现，也是五家里最完整的：它在建立连接的那一刻检查解析后的地址，而不是在检查和使用之间留出时间差——这就堵死了 DNS 重绑定攻击（先解析到合法地址、实际连接时换成内网地址）；同时应用 IP 段的允许与拒绝列表；并且在启动时就拒绝不安全的 base URL，而不是等到第一次请求才发现。代价是工程量：这是五家里做得最多的。

Weaviate 的 PR #12961 走的是最小修复路线：把 Google 模块的 apiEndpoint、region、location 三个参数约束到 Google API 的主机范围内。思路很直白——这个功能实际需要访问的主机就这么多，别的统统不让去。改动小、回归风险低，适合已经上线的服务热修复。

法国 DINUM 的 PR #126 标题就叫"harden SSRF on external APIs"，开篇第一句是"Reported by Syed Anas Mohiuddin"。一个国家政府的官方服务器，和一家银行的文档工具栽在同一个坑里，这个事实本身比修复细节更有分量。

Tangerang 市政府的修复赢在速度：9 月 2 日收到报告，commit 2bbfe12 当天修复，9 月 3 日 GHSA-pw2j-pj4h-f5vg 公告发布，评级 high。一天走完"报告—修复—公告"全程，这个响应速度值得所有维护者学习。但它的教训同样值得记住：出事前的"防护"只拒绝字面 IP，这种检查在 DNS 面前形同虚设——校验域名必须解析后再看 IP，这是 SSRF 防御里最基础也最容易被跳过的一课。

摩根大通的案例则贡献了另一条教训：同一个白名单必须应用到每一个会发起抓取的工具，而不只是第一个写下的那个。read_documentation 有检查、related() 没有，这种"一半有锁一半没锁"的状态，在功能迭代中极其常见，也是代码评审时最值得加一条 checklist 的地方。

综合起来，一份合格的 SSRF 防护有四条：解析后的地址在连接时校验、关掉自动重定向或逐跳校验、每个抓取入口统一走同一套白名单、上游返回体在落日志前脱敏。谷歌做了全套，Weaviate 做了最关键的一条，Tangerang 证明了响应速度可以很快，摩根大通证明了"漏掉一个入口等于没做"。没有哪家是完美的，但五家加在一起，恰好拼出一份完整的答案。

MCP Agent 工具链结构示意图

给 vibe coder 的最小防御清单

这件事和 vibe coding 群体的关系，比看起来更直接。每天都有人用 AI 生成自己的 MCP 服务器——给 Agent 接数据库、接内部 API、接自动化脚本，写起来飞快，发布也飞快。Mohiuddin 在披露页里写得很直白：MCP 服务器的发布速度已经超过了任何人的审查速度，而同样的两个错误假设还在随着每个新服务器一起发布。如果你是自己搭工具链的一人开发者，下面这份清单是按优先级排的，每一条都对应上面某个真实案例：

• 先盘点你的工具面。列出你正在用的 MCP 服务器里，哪些工具接受 URL、路径、接口地址这类参数。凡是"Agent 传什么、服务器就去抓什么"的工具，都是 SSRF 候选。这是成本最低、收益最高的一步。
• 别信任工具返回的文本。Agent 读到的网页、文档、API 返回都可能是攻击者布置的。不要让 Agent 把工具返回的内容原样喂给高权限工具（写文件、调基础设施、发请求），中间至少要有一道校验或确认。
• 自部署的服务器，默认只绑 loopback。日本数字厅的 jgrants-mcp-server 被指出没有任何认证，Mohiuddin 提的 PR #6 要求必须显式 opt-in 才允许绑定非回环地址——这个原则适用于所有人：在你明确知道自己在做什么之前，服务器只听本地。
• 四个修复动作按需照抄。关掉 HTTP 客户端的自动重定向（或逐跳校验）；对解析后的 IP 做允许/拒绝判断，防 DNS 重绑定；域名白名单要覆盖每一个抓取入口；日志里出现上游响应体先脱敏。谷歌的 PR #3448 是现成的参考实现。
• 用扫描器扫一遍，但别迷信它。mcp-safeguard 这类工具能从工具暴露面做黑盒测试，不需要源码，适合快速摸底。但作者自己承认模式匹配会漏掉很多，关键路径还是要人去读代码——尤其是 fork 来的项目，把原版和你的版本 diff 一遍，摩根大通的坑就是这么被发现的。
• 订阅你所用服务器的安全公告。这五起案例里有 16 个 GitHub 安全公告把 Mohiuddin 记为报告者，覆盖命令注入、认证缺口、会话劫持、凭据泄露等类型。你用的服务器如果连 advisory 都没有，本身就是一个信号。

更深一层的判断是：vibe coding 把"写一个服务器"的门槛降到了零，但"写一个安全的服务器"的门槛没有跟着降。AI 生成代码擅长把功能跑通，不擅长追问"这个参数是谁控制的"。在协议本身不设防的情况下，这个追问只能由人来完成——至少目前是。

10 月 23 日 MCPCon：还没讲完的下半场

2026 年 10 月 23 日，Mohiuddin 将在圣何塞的 MCPCon North America 上演讲，主题就是这次跨厂商的复现图谱——用他的话说，是"五月的论点，加上五次确认"。有几个悬念值得在那之后继续追。

第一，美国联邦政府的五台 MCP 服务器。2026 年 9 月 2 日，他以私有 GitHub Security Advisory 的形式提交了五个发现：退伍军人事务部的福利申请服务器、CMS 的 Blue Button 服务器、regulations.gov、USASpending 和 CDC PLACES 服务器，问题都出在日志脱敏缺失这类"第二失效模式"上。截至披露页撰写时，五个全部还在 triage，没有修复。出于负责任披露，他没有公开代码级细节——这意味着在修复落地之前，公众只能看到"问题存在"，看不到"问题在哪"。这五个的修复进度，是检验美国政府 AI 基础设施响应能力的一个公开窗口。

第二，日本数字厅的 PR #6。9 月 7 日提交的加固 PR（要求显式 opt-in 才绑定非回环地址、限制附件写入大小）至今没有被合并。一个未合并的安全 PR 和五个未修复的联邦服务器放在一起看，说明这场"结构性修复"的下半场才刚刚开始：发现漏洞的那个人已经证明了问题存在，但让全世界几千个 MCP 服务器真正改过来，是另一个量级的工作。

第三，Mohiuddin 说他"还在找"。他的披露页列出了 16 个以他为报告者的 GitHub 安全公告，问题类型早已超出 SSRF：命令注入、认证缺口、会话劫持、凭据泄露、对早期修复的绕过。他还提到 github-mcp-server、mongodb-mcp-server、salesforce-mcp-server 等项目里已有他提交的修复被合并，另有几份报告还在 triage。SSRF 只是最容易讲清楚的一个切面，MCP 工具面上的问题清单还在变长。

对 vibe coding 生态来说，这次事件真正的意义不在于五个 CVE 式的编号，而在于它提前演示了智能体时代的安全范式转移：当 AI 开始替人调用工具，信任边界就不再画在"代码是谁写的"，而是画在"数据是谁控制的"。协议给了所有人同一套默认配置，而默认配置里没有安全——这句话在 2026 年 10 月之后，应该成为每个发布 MCP 服务器的人案头的一句提醒。10 月 23 日的演讲会不会推动协议层面真正的强制安全要求，是这件事留给整个生态的最大悬念。