你以为用了官方 MCP SDK 就安全了？今天 Rust 官方 MCP SDK 三天内来了四个 CVE

写过 MCP 接入的都习惯信任官方 SDK——毕竟底层库出问题概率低，审计也容易。但这个假设最近被打脸了。

2026 年 9 月 16 日，GitHub 对 rmcp（Rust 官方 MCP SDK）连发两个高危 CVE，第二天又追加一个中危和一个高危，四天内四个漏洞影响全部基于 rmcp 构建的 MCP 服务。

CVE-2026-63127（CVSS 8.2）：OAuth token 被你的 MCP 服务器反向窃取

OAuth Protected Resource 元数据发现流程（RFC 9728 §3.3 和 §7.3）要求 MUST 校验 resource 字段，但 rmcp 的 ResourceServerMetadata 结构直接漏掉了这个字段。攻击者只需要部署一个恶意的 MCP server，在元数据中发现真实的授权服务端点，就能把受害者的 OAuth 流程劫持过去，拿到发给别人服务器的 access token。整个过程受害者无感知，因为授权页面看起来完全正常。

CVE-2026-63128（CVSS 7.5）：每发一个畸形请求就漏一个 Session handle，每天 75GB

handle_post 在验证请求体之前就先分配了 LocalSessionHandle。攻击者每秒发 2000 个畸形 JSON-RPC POST，Session handle 就会以相同速度泄漏到内存里。实测换算下来，每天约 1.7 亿条泄漏记录，占用 75GB 内存。对长时间运行的 MCP 服务来说，这是个静默的内存炸弹。

CVE-2026-64684（CVSS 6.8）：你的 X-API-Key 被重放到了陌生域名

StreamableHttpClientTransport 的默认 reqwest 客户端没有覆盖重定向策略，会自动跟随 307/308 重定向。而 custom_headers（如 X-API-Key、X-Auth-Token）没有被标记为 sensitive，不会像 Authorization/Cookie 那样被丢弃，而是完整地跟随重定向发到攻击者指定的任意域名。这意味着只要你的 MCP 客户端访问了一个会 307 重定向的服务器，API key 就已经被送到对方手里了。

CVE-2026-64683（CVSS 6.8）：OAuth 资源发现阶段 SSRF

发现元数据时从 WWW-Authenticate 的 resource_metadata= 参数取 URL，没有任何同源检查或私有网络限制，可以打 localhost、RFC 1918 地址、云元数据端点。

三个漏洞的共同问题是什么

三个都是”信任边界错位”：把第三方提供的数据当成了可信输入。OAuth 流程里信任了 MCP server 返回的 resource 字段；Session 管理里信任了请求体在分配内存前就合法；HTTP 客户端信任了重定向目标不会拿走 header 里的凭证。单独看每个都是工程疏漏，放在一起看就是 MCP 生态在快速扩张时集体忽略了安全边界这个基础课。

你能做什么

第一步：检查你的 Cargo.lock 里 rmcp 的版本。如果 ≤1.7.0 或在 1.4.0~2.0.0 之间，分段升级——四个漏洞的修复分散在 1.4.0、2.0.0、2.1.0 三个版本里，一次升级不能清除所有风险。

第二步：只连接你信任的 MCP server。和陌生 server 建立连接时默认视为不可信，尤其在 OAuth flow 阶段，不要轻信对方的元数据响应。

第三步：如果用 custom_headers 传 API key，显式检查你的 MCP 客户端有没有处理重定向时清除敏感 header 的逻辑。这个问题不只 rmcp 有，其他语言的 SDK 也可能存在类似行为。

MCP 这三个月密集爆出的 CVE 已经开始从”单个服务实现缺陷”蔓延到”官方 SDK 架构性漏洞”。审计自己写的 MCP server 已经不够了——现在你还得盯着你依赖的底层库版本。这件事，Agent 接入量越大的团队越要重视。