30天内3起MCP认证漏洞：根源都是"轻信对方说的话"

一个月，三起漏洞，同一个病根

在短短30天内，MCP（Model Context Protocol）生态连续曝出三起认证相关的安全漏洞，分别出现在 MCP Python SDK、Rust SDK（rmcp）以及 LiteLLM 中。三者表面上看是互不相关的独立问题，但剥开实现细节后会发现，它们共享着同一个致命的设计习惯——信任通信对端自报的信息，却从未对其进行验证。

这类问题在安全领域并不新鲜，但它反复出现在AI基础设施的核心组件中，说明随着 MCP 协议快速普及、各语言 SDK 争相落地，安全验证环节正在被开发速度所牺牲。对于正在把 MCP 接入生产环境的团队而言，这不是一个可以忽视的信号。

MCP（Model Context Protocol）是由 Anthropic 于2024年底推出的开放协议，旨在为大语言模型提供标准化的"工具调用"接口，使模型能够统一接入文件系统、数据库、API 等外部资源。其设计思路类似于 USB-C 的"通用接口"理念——开发者只需按照协议规范实现一次，即可让任意兼容的 AI 应用调用。正因为 MCP 承载着模型与真实世界之间的权限通道，其认证机制的健壮性直接决定了整个调用链的安全边界。目前 MCP 已有 Python、Rust、TypeScript 等多语言官方 SDK，以及大量社区实现，生态扩张速度远超安全审计的跟进节奏。

三起漏洞的共同模式

MCP 作为连接大模型与外部工具、数据源的协议，天然处于一个高信任、高权限的位置。一旦认证环节出现缺口，攻击者就可能越过身份校验，获取本不该暴露的访问权限。

这三起漏洞的共性非常清晰：

• MCP Python SDK 接受了认证输入，却没有人真正去验证它；
• Rust SDK（rmcp） 同样在认证流程中放行了未经核验的数据；
• LiteLLM 作为模型网关层，也犯了相同的错误——把对端声称的身份当成了既定事实。

换句话说，系统在收到"我是谁"的声明后，直接采信，而没有执行"你凭什么证明你是你"这一关键步骤。认证的本质是验证，而一旦验证缺位，认证就退化成了形式。

为什么"轻信"如此危险

在分布式系统和协议交互中，任何来自外部的输入都应被视为不可信。认证令牌、身份声明、来源标识——这些数据哪怕看起来格式正确，也必须经过服务端的独立校验。当开发者默认"对方发来的信息是真实的"，攻击者就获得了伪造这些信息的空间。

MCP 场景下的风险尤其突出：大模型往往被赋予调用工具、读写数据的能力，认证一旦被绕过，影响范围可能从单次会话扩散到后端系统本身。

这类漏洞在安全分类上通常被称为"身份验证缺失"（Missing Authentication）或"认证绕过"（Authentication Bypass），其技术根源是混淆了"身份声明"（Authentication Claim）与"身份证明"（Authentication Proof）两个不同阶段。健壮的认证流程应当包含：接收令牌或凭据、在服务端独立向可信来源（如签名校验、OAuth 授权服务器、数据库记录）比对验证、验证通过后才授予权限。跳过中间的"独立校验"步骤，等同于只看身份证上的名字便放行，而不核实证件的真伪。在 JWT（JSON Web Token）场景下，这种错误的典型表现是服务端直接解码 token payload 而不验证签名，导致任何人都可以伪造任意身份。

受影响的范围

从原始披露看，问题横跨了三种技术栈：Python、Rust 以及作为统一网关的 LiteLLM。这意味着无论团队选择哪种语言实现 MCP 客户端或服务端，都可能处于风险之中。

LiteLLM 的卷入尤其值得警惕。作为广泛使用的多模型调用网关，它处在大量应用的流量入口，其认证缺陷的潜在波及面要比单个 SDK 更广。使用上述任一组件的开发者，都应当尽快确认自己所用版本是否包含修复。

LiteLLM 是一个开源的 LLM 代理网关，支持通过统一接口调用 OpenAI、Anthropic、Gemini、Mistral 等数十家模型提供商的 API，在企业内部常被用作"模型路由层"，集中处理鉴权、限流、日志和成本归因。由于它位于应用与所有模型服务之间，一旦其自身认证存在缺陷，攻击者无需针对某个具体模型服务，仅需突破网关层即可横向访问该组织接入的全部模型资源，潜在影响远大于单点 SDK 漏洞。这也是安全领域中"信任链"（Chain of Trust）被破坏的典型场景——最薄弱的一环决定整体防线的高度。

如何堵住这个缺口

这三起漏洞给出的最大启示，是一条可以普适落地的安全准则：永远不要信任通信对端自报的内容。基于这一原则，接入 MCP 的团队可以参考以下检查清单：

• 验证一切认证输入：令牌、签名、身份声明都必须在服务端独立校验，而非直接采信。
• 区分"声明"与"证明"：对端说自己是谁，和对端能证明自己是谁，是两回事。认证逻辑必须要求后者。
• 及时升级组件：确认 MCP Python SDK、rmcp、LiteLLM 均已更新到修复版本。
• 审查自有实现：如果团队自行扩展或封装了 MCP 认证逻辑，需逐项排查是否存在同类"默认信任"的代码路径。
• 把外部输入视为不可信：这应成为所有协议交互代码的默认假设，而非事后补救。

快速演进中的安全债

MCP 生态正处于爆发期，各语言 SDK 和配套工具层出不穷。但这波快速迭代也暴露出一个结构性问题：安全验证往往是功能上线后才被补齐的环节。一个月内三起同根漏洞，恰恰说明"轻信对端"并非某个开发者的个别疏忽，而是整个生态在高速推进中共享的盲点。

对使用者来说，务实的做法是把安全前置：在接入任何 MCP 组件前，先明确它的认证验证逻辑是否可靠，而不是假设成熟项目一定做对了基础校验。对维护者来说，这三起案例应当成为代码审查的固定检查项——认证路径上每一处"信任"，都需要一个明确的"验证"来支撑。