协议转向：被注入的工具输出让 MCP 服务器沦为 SSRF 跳板

What is this?

独立研究员 Syed Anas Mohiuddin 在 2026 年 10 月 5 日发布的更新中，描述了一种被他称为“protocol pivoting”的模式，并将其与他向多个 Model Context Protocol（MCP）服务器报告的服务端请求伪造（SSRF）缺陷联系起来。10 月 6 日的媒体报道称，Google、JPMorgan Chase、Weaviate、法国 DINUM 以及印尼 Tangerang 市均已修复各自的实例。另外，针对 Google MCP Toolbox for Databases 的 GitHub 安全公告发布于 2026 年 7 月 31 日，Wazuh MCP 服务器的公告发布于 2026 年 9 月 3 日。

核心并非新的漏洞类别，SSRF 由来已久。新意在于投递路径：植入 MCP 工具返回内容中的文本，通过普通的代理间委派抵达高权限组件。

How it works

根据研究员的文章，攻击链有两个要素：

1. 对委派的信任。 工具输出中形似任务指令的文本被编排代理转发给子代理，子代理把它当作来自可信同伴的合法委派。
2. 用未经验证的参数构造出站请求的 MCP 服务器。 已发布的公告描述了典型缺陷：HTTP 客户端跟随重定向却不重新检查目的地（Google 的 toolbox，受影响版本 0.3.0 至 1.4.0），以及只拒绝字面私有 IP、却不拒绝解析到私有地址的主机名的校验（Wazuh 服务器）。

两者结合后，请求从信任边界内部发出，带有子代理的网络位置和凭据。文章还指出第二种失效模式：服务器未脱敏就记录完整的上游 API 响应，使普通错误也会泄露敏感数据。研究员的说法是各组件“均按设计运行”，问题出在组合而非某个单一产品。

媒体流传的数据（约 7,000 台被扫描的 MCP 服务器中 36.7% 存在 SSRF）来自研究员自己的扫描，据我们所能核实，尚无独立复现。该数字与我们 2026 年 7 月报道过的早期生态测量方向一致。

Why it matters

代理流水线越来越多地串联编排器、子代理和工具服务器。只要任何一环把上游文本当作指令，低权限的内容来源就能驱动高权限的网络客户端。受影响机构涵盖云厂商、银行、向量数据库厂商和公共部门项目，说明该模式在服务器实现中较为普遍。研究员还称，截至 10 月 6 日仍有若干政府服务器未修复；本文不点名。

Defenses

• 先解析、再在连接时校验：检查解析后的 IP（回环、链路本地、私有网段、云元数据地址），并将连接固定到该地址以抵御 DNS 重绑定。
• 禁用自动重定向，或对每一跳重新校验。
• 按工具设置主机白名单，凡是抓取 URL 的工具都应使用白名单而非黑名单。
• 不要把工具输出当作委派：编排器应将来自工具的文本标记为数据，子代理应要求任务指令经由有类型、经认证的通道到达，而非自由文本。
• 按代理划分凭据，不要共用一个凭据池，并让元数据服务不可达（例如强制 IMDSv2 或屏蔽该端点）。
• 在记录日志或返回错误前，对上游响应脱敏。
• 用面向 SSRF 的扫描器检查自己的服务器，并审查日志中发往内部网段的出站请求。
• 将 Google MCP Toolbox for Databases 升级到包含 SSRF 修复的版本（研究员引用的是 1.5.0），并应用 Wazuh MCP 服务器的修复。

Status

项目	状态	参考
Google MCP Toolbox for Databases	已修复（公告发布于 2026-07-31；据称 1.5.0 含修复）	CVE-2026-14540, GHSA-3x3x-8ffg-ghcv
Wazuh MCP 服务器（Tangerang）	已修复（公告 2026-09-03）	GHSA-pw2j-pj4h-f5vg
JPMorgan、Weaviate、DINUM 实例	据报已修复	见媒体报道
部分美国政府服务器	截至 2026-10-06 据报未修复	未点名