Model Context Protocol 已经是智能体连接外部工具与数据源的事实标准，可它从设计上并不强制安全。当智能体开始跨内部系统真的动手，协议那一处「默认信任」的裂缝就变得刺眼。9 月底，安全研究团队 Cleafy（经 Cycode 独立复核）披露了官方 MCP Python SDK 的一处高危逻辑缺陷：在校验重定向 URI 时存在错误，导致恶意 MCP 服务器可以把一次正常的 OAuth 握手调包，让本应留在客户端的访问令牌连同 client secret 与 PKCE 证明密钥一起流向攻击者可控端点。这不是某家厂商服务器的实现 bug，而是官方 SDK 本身的信任假设出了岔子。
把漏洞拆开看会更清楚。一个 AI 智能体（作为 MCP 客户端）连接到一个第三方 MCP 服务器时，后者会发起 OAuth 授权流程，并把授权服务器返回的令牌交给客户端。问题出在客户端没能校验「令牌该回哪个地址」——恶意服务器只要把重定向地址改写成自己控制的端点，SDK 就照单全收，于是 PKCE 这套本用来防授权码拦截的机制被整段绕过。攻击者拿到的不只是一次性的授权码，还有长期有效的 client secret 与 PKCE 证明密钥，意味着在没人工确认的那类机器对机器连接上，凭证可以静默地持续被利用。报告给出的影响范围是 1.x 的 1.9.1–1.29.1 与 2.x 的 2.0.0–2.1.1，补丁分别为 1.30.0 与 2.2.0；机器对机器（ClientCredentials / PrivateKeyJWT 提供方）路径 CVSS 达到 7.5，交互式提供方为 6.5。本地 stdio 客户端、以及自带外部托管令牌的客户端不受影响。
这类缺陷的可怕之处不在单点，而在结构。MCP 的便利恰恰来自「客户端可以连接任意第三方服务器」，而安全边界本就薄；当协议默认信任服务器提供的元数据、SDK 又没在交换环节校验，那么只要列表里有一个被攻陷或本就恶意的服务器，Agent 的整条凭证链就暴露。这和我们此前多次写过的 MCP 治理真空是同一类病灶——工具投毒、提示注入经工具回传、混淆副手利用，本质都是「描述与行为不一致」这一条信任假设被反复击穿。补一个 SDK 版本能堵当前这一处，但生态级的信任模型还得靠网关、允许清单与凭据隔离来补。
落到工程动作，建议很具体。其一，把 MCP Python SDK 升到 1.30.0 或 2.2.0，没有安全绕法；其二，升级后去身份提供方的令牌签发日志里翻一遍脆弱窗口内建立的连接，把说不清来源的令牌一律作废；其三，把每个 MCP 服务器连接当成第三方 API 信任关系来管——显式允许清单、对服务器包做哈希钉扎或代码签名、给每个连接只发它真实需要的那档范围令牌。对已经在大批量接 MCP 的智能体平台，这几条该写进上线前的硬性检查单，而不是出事后再补。
最后把口径摆正：截至报道时尚未见官方 CVE 编号，信息来自安全研究团队的披露与多家行业媒体的交叉印证，属「已披露、待厂商与社区大规模复核」的阶段。它提醒行业的不是「MCP 不能用」，而是「用得越快、信任模型越要跟上」——智能体连的工具越多，凭证这道闸越不能只靠单个 SDK 的自觉。把第三方 MCP 服务器当作和 OAuth 应用对接同等级的信任对象来审，才是这场漏洞真正的收获。