事件概述
独立安全研究员 Syed Anas Mohiuddin 在 10 月的研究更新中披露，五家彼此不共享代码、行业与地域的机构，在各自的模型上下文协议（MCP）服务器上修复了同一类服务端请求伪造（SSRF）漏洞，包括谷歌、摩根大通、向量数据库厂商 Weaviate、法国部际数字事务局（DINUM）与印度尼西亚唐格朗市政府。
该研究验证了研究员今年 5 月的判断：这不是个别实现疏忽，而是 MCP 生态的结构性缺陷。另有针对五个美国联邦政府 MCP 服务器的报告自 9 月 2 日提交后仍未修补。
技术细节
MCP 是 AI 智能体调用外部工具与数据源的标准协议。SSRF 的成因是：MCP 服务器接受智能体传入的 URL、路径或端点并据此发起对外请求，却没有校验该地址实际解析到哪里，于是驱动智能体的一方实际上决定了服务器以自身网络身份访问什么，包括内网系统。
以谷歌 MCP Toolbox for Databases 为例，通告编号 CVE-2026-14540，CVSS 8.0，影响 0.3.0 至 1.4.0。问题在于 HTTP 客户端未设置限制性重定向策略，也未校验目标 IP，构造路径参数即可把请求导向内部或任意外部端点。谷歌在 1.5.0 中加入 SSRFGuard，防范地址校验与连接之间的 DNS 重绑定窗口，并提供私有网段开关与允许、阻断 IP 段列表。
Google CVE-2026-14540 8.0 MCP Toolbox 0.3.0-1.4.0，修复 1.5.0
JPMorgan 中危 related() 直接抓取调用方 URL
Weaviate 已修复 端点限制为谷歌 API 主机
DINUM 已修复 校验连接时 IP 并复检每跳重定向
Tangerang 高危 防护仅拒绝字面 IP，未解析主机名研究员把更广的攻击类别称为“协议跳板”：攻击者在 MCP 工具返回的内容中埋入形似任务指令的文本，主智能体读取后作为常规委派交给子智能体执行，子智能体因信任主智能体而不加质疑。若其 MCP 服务器存在缺陷，恶意请求便从信任边界内部、以该智能体权限发起。链条上每个环节都只是按设计工作，这正是它难以察觉的原因。
影响评估
目前受影响方多在内部或开源项目中自查自修，未见公开的武器化利用。风险点在于这类漏洞横跨超大规模云厂商、大型银行与国家级政府部门，说明它不依赖某一套具体代码，而是会被反复复现。
日志处理不当是同批暴露的另一种失效模式：部分 MCP 服务器把上游 API 的完整错误响应原样写入集中日志而不脱敏。以美国退伍军人事务部福利申请接口为例，这类日志可能包含姓名、社会安全号、出生日期与住址。研究员在维护方修补前未公开代码级细节。
业内有观点认为“协议跳板”本质是间接提示注入，跨协议并非必要条件。名称之争不影响结论：智能体读取的任何文本都可能携带指令，任何无条件信任其他智能体的环节都会放大指令。
修复建议
- 升级 Google MCP Toolbox for Databases 至 1.5.0 以上；Rapid7 Bulk Export MCP 升级至 0.6.2；其余开源项目按仓库提交记录更新。
- 在连接建立时校验目标 IP，而不只在请求发起前检查；对每一次重定向跳转重新校验，并拒绝走代理的请求。
- 配置允许与阻断 IP 段列表，默认禁止访问回环、私有网段与云元数据地址。
- 对 MCP 边界流入的数据按不可信处理：上游错误响应与 API 返回内容须做字段级脱敏，禁止原样写入集中日志。
- 在编排层校验委派指令来源，限制子智能体在未复核前执行工具返回内容中的操作。