CVE-2026-32211：Azure MCP Server 缺失身份验证

这是什么？

2026 年 4 月 2 日，微软发布了 CVE-2026-32211，这是 Azure MCP Server 中的一处信息泄露漏洞。NVD 条目收录的描述十分直白：Missing authentication for critical function in Azure MCP Server allows an unauthorized attacker to disclose information over a network（Azure MCP Server 的关键功能缺失身份验证，使未授权攻击者可通过网络泄露信息）。

其底层弱点归类为 CWE-306 — Missing Authentication for Critical Function（关键功能缺失身份验证）。说白了，一个本应要求调用方证明身份的功能并未这样做：一个经由网络抵达服务器的请求，便能取回它本不该看到的数据。微软的 MCP 工具会暴露对云资源的操作；一个对任何人都应答的 MCP 端点，正是 CWE-306 所指的那种「关键功能」。

值得关注的并非它有多奇特——恰恰相反——而是它是一个干净、具名、由厂商确认的实例，体现了 Model Context Protocol 部署最常见的失败方式：在网络上暴露，前面却没有任何身份验证。

工作原理

这里没有精巧的载荷，我们也刻意不公布任何载荷。其机制在于缺少一项控制，而非存在某种技巧：

1. 一个功能被暴露在网络上。 Azure MCP Server 会响应那些返回其所连接环境信息的请求。
2. 身份验证检查缺失。 依据 CWE-306，该关键功能在执行前未核验调用方身份，因此一个未授权请求（按 CVE 文本所述）被照常处理。
3. 信息被返回。 从未认证的攻击者收到了本应由凭证保护的数据。

评分本身也讲述了如何阅读一条 CVE 的有用一课。作为分配机构（CNA），微软将该漏洞评为 9.1 严重，向量为 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N。而 NVD 分析师在一个维度上有不同看法，将其评为 7.5 高危，向量为 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N。双方都认同该漏洞可经网络访问（AV:N）、无需权限（PR:N）与交互（UI:N），并泄露机密性（C:H）。二者仅在完整性上分歧：微软给出 I:H，NVD 给出 I:N。当两个权威来源为同一漏洞给出两个分数时，这不是可忽略的错误，而是提醒你去读向量，而非标题里的数字。

微软将该问题标记为**「独占托管服务」**（exclusively hosted service）漏洞。按微软的 CVE 约定，这意味着受影响组件运行在微软云中，修复由微软侧完成，客户无需安装补丁——发布 CVE 是出于透明。但这并不让教训变得可选：任何运行自己所控制的 MCP 服务器的人，都继承了同样的失败模式。

为何重要

MCP 服务器处于一个危险的交汇点。它们的设计初衷是赋予 LLM 智能体真实能力——读取某项资源、查询某个系统——这使得 MCP 端点在结构上就是通往数据与操作的网关。把它放在没有身份验证的网络上，你就构建了一个通往其所能触及一切的开放 API。

CVE-2026-32211 只是本站整个春季所追踪模式中的一个数据点。2026 年 5 月一项针对 7973 台在线远程 MCP 服务器的研究发现，40.55% 的服务器完全不做身份验证就暴露其工具，且每一台受测的启用 OAuth 的服务器都至少存在一处缺陷（参见远程 MCP 服务器：40% 无身份验证）。互联网级扫描对整个技术栈给出了相同结论——反复出现的失败源于宽松的默认配置，而非奇异的漏洞。OWASP 2026 年 6 月的《State of Agentic AI Security》报告把协议与供应链层置于核心，列举的是 CVE 而非假设。当微软自家的官方 MCP 服务器登上这份名单，「这不会发生在正经厂商身上」的说辞便不复存在。

「信息泄露」这一定性也低估了智能体风险。只读泄露本身已属糟糕，但在智能体流水线中，同样这种未经认证的可达性会成为喂养后续步骤的立足点——把数据访问、不可信内容与行动能力结合起来，你就又回到了致命三要素。

防御

把每一台 MCP 服务器——无论托管还是自建——都当作需要认证、需要网络隔离的服务，绝不要当成随手放在某个端口上的便利工具。

1. 对服务器做认证，而不只是对模型。 在执行任何工具功能前，要求经过核验的调用方身份（mTLS、带令牌校验的 OAuth，或一个强制执行此项的网关）。CWE-306 的修复方式就是补上那个缺失的检查。
2. 不要把 MCP 暴露给无需访问它的网络。 默认绑定到 localhost 或私有网段；将任何远程访问置于一个终结身份验证的反向代理之后。这与微软针对托管情形的缓解建议一致（限制网络访问，置于认证访问之后）。
3. 对服务器的可达范围施加最小权限。 即便已认证，MCP 服务器也应只持有严格限定于其工具所需资源的凭证，以便一旦被绕过也泄露更少。
4. 盘点你的 MCP 攻击面。 多数组织无法列出自身内部正在运行的 MCP 端点。像扫描其他暴露服务一样扫描它们，并逐一检查身份验证要求——参见 NSA 的 MCP 安全设计考量。
5. 读向量，自定严重度。 不要让单一的 CVSS 数字主导分级。对 CVE-2026-32211，微软的 9.1 与 NVD 的 7.5 之差完全在于完整性这一问题——判断哪一种与你的部署相符。

现状

项目	来源	日期	备注
CVE-2026-32211 披露	微软 / NVD	2026-04-02	Azure MCP Server 关键功能缺失身份验证（CWE-306）
微软（CNA）评分	MSRC 公告	2026-04-02	9.1 严重 — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
NVD 评分	NVD 分析	2026-04-06	7.5 高危 — C:H/I:N/A:N（在完整性上有分歧）
修复	微软 CVE 约定	—	标记为「独占托管服务」；由微软侧修复，客户无补丁
更广背景	OWASP / arXiv 扫描	2026-05 至 06	约 40% 的远程 MCP 服务器在无身份验证下运行

要点不是 Azure MCP Server 格外疏忽，而是「先部署 MCP 端点，再补身份验证」是整个行业普遍存在的默认做法，而 CVE-2026-32211 正是这一错误冠以大厂之名、附带 9.1 CVSS 的版本。如果你在任何地方运行 MCP，今天要回答的问题很简单：你的哪一台服务器会回应一个陌生人？

本文出于防御与教育目的，总结公开的、由厂商披露的漏洞信息，不复现任何利用代码。