MCP服务器爆SSRF漏洞：Google、摩根大通等五家机构同中招

一个被忽视的安全盲区：MCP服务器的SSRF问题

当AI Agent需要获取外部信息时，它通常会通过MCP（Model Context Protocol）服务器来发起请求。问题在于：如果服务器盲目信任Agent传入的地址，攻击者就能让服务器去访问本不该访问的内部资源。

据TNW本月报道，Google、JPMorgan Chase、Weeviate、法国数字事务局以及印度尼西亚某市政府，各自修复了其MCP服务器中同一类型的漏洞——服务端请求伪造（SSRF）。Google将其版本评为高危。

这些机构的MCP服务器在构建出站请求时，直接使用Agent提供的地址，却没有验证该地址实际解析到哪里。攻击者可以借此让服务器访问内部网络、云元数据接口或其他敏感资源。

SSRF为什么在MCP场景下格外危险

传统Web应用中的SSRF已经足够棘手，而MCP服务器的特殊性让问题进一步放大。

MCP服务器本质上是一个“代理执行层”：Agent负责推理和决策，服务器负责实际发起网络请求。这意味着服务器拥有比普通API网关更直接的网络访问能力。一旦地址验证缺失，服务器就可能成为攻击者进入内网的跳板。

更麻烦的是，Agent的请求往往带有动态性——它会根据对话上下文临时决定要获取什么资源。这种灵活性使得静态白名单很难覆盖所有合法场景，开发者容易为了便利而放松校验。

SSRF（Server-Side Request Forgery） 的核心机理在于：攻击者并不直接访问目标资源，而是诱使一个具备网络访问权限的服务端组件替自己发起请求。典型后果包括探测内网拓扑、读取云环境中的实例元数据接口（如AWS的 169.254.169.254，其中可能包含临时凭证）、访问仅对内网开放的管理后台或数据库。历史上，2019年Capital One数据泄露事件即与SSRF结合元数据接口有关，导致上亿用户信息外泄。

防御SSRF的关键难点在于校验时机与校验对象的一致性。常见做法包括：解析目标域名得到IP后再判断其是否落在私有地址段（RFC 1918）、链路本地地址、回环地址等受限范围内；限制协议仅允许 http/https；以及在每次重定向后重新执行校验。DNS Rebinding 是另一类绕过手法——攻击者让域名第一次解析到合法公网IP通过校验，随后切换到内网IP，因此解析与连接之间若存在时间差，校验就可能失效。

五家机构，同一个错误

这五家机构规模、行业、地域各不相同，却踩了同一个坑。

据TNW报道，这些漏洞均由独立安全研究员Syed Anas Mohuddin一人发现并撰写报告。他本月公开了相关细节。

从Google到摩根大通，再到法国政府机构和印尼地方政府，说明这并非某个团队的疏忽，而是MCP生态中普遍存在的设计盲区。当大家都在快速搭建Agent基础设施时，安全性往往被放在功能之后。

Google将其MCP服务器的SSRF漏洞评为“高危”，也从侧面印证了这类问题的实际影响面。

修复的核心逻辑

修复方案本身并不复杂：MCP服务器在发起出站请求之前，必须自行解析并校验目标地址。

具体来说，服务器需要检查目标地址是否解析到内部IP段、云元数据端点或其他受限资源。对于重定向也要格外小心，因为一次302跳转就可能绕过初始校验。

正如原文所总结的：“一个为Agent执行获取任务的工具，必须自己检查目的地。”这句话点出了MCP服务器安全设计的核心原则——信任边界不能外移。

MCP（Model Context Protocol） 是Anthropic于2024年11月开源的协议，用于在AI模型与外部工具、数据源之间建立标准化连接。它采用客户端-服务器架构：Agent侧的MCP客户端负责与模型交互并调用工具，MCP服务器则把具体的资源访问能力（读写文件、查询数据库、调用HTTP API等）以“工具”形式暴露出来。

这种设计的价值在于解耦——工具实现方无需关心模型细节，Agent也无需为每个数据源编写定制代码。但它同时引入了新的信任边界：Agent的推理过程可能被提示注入攻击操纵，从而生成恶意请求参数。因此MCP服务器必须把来自Agent的参数视为不可信的外部输入，而不能因为“请求来自自家Agent”就默认其安全。这正是本批漏洞暴露出的认知偏差。

云元数据端点是云厂商为运行中的实例提供配置与凭证信息的内部服务，典型地址为 169.254.169.254（AWS、Azure、GCP等普遍采用类似地址）。它不经过公网，只对实例内部可达，因此常被SSRF攻击者当作首要目标——一旦读取到实例角色的临时凭证，就可能横向扩展到云账户内的其他资源。

部分云厂商已推出防护措施，例如AWS的IMDSv2要求请求携带通过PUT获取的令牌，并限制跳数，从而显著提高SSRF利用难度。但对MCP服务器而言，更根本的做法仍是在出站请求前统一拦截所有指向链路本地地址、私有网段和回环地址的目标，并对重定向逐跳校验。

对开发者的启示

这批漏洞的集中曝光，给正在构建Agent应用的团队提了个醒。

MCP服务器不是简单的HTTP转发器，它承担着安全把关的责任。Agent传来的任何地址都应被视为不可信输入，需要经过解析、校验、限制重定向等完整流程。

同时，这也暴露出当前MCP生态在安全规范上的缺失。当协议本身没有强制要求地址校验时，各实现方的安全水位就参差不齐。随着越来越多企业将MCP服务器接入生产环境，建立统一的安全基线会变得越来越紧迫。

对独立研究者而言，Syed Anas Mohuddin的工作也说明：不同公司犯同样的错误，意味着系统性的安全问题值得被持续审视。