Azure MCP Server 的 SSRF 漏洞可能将其托管标识令牌泄露至某个 URL

Microsoft 于 2026 年 3 月 10 日发布了 CVE-2026-26118：这是Azure MCP Server Tools中的一个服务器端请求伪造漏洞，该包允许 AI 代理和 MCP 客户端以自然语言对 Azure 资源执行操作。能够与由 MCP 支持的代理交互的攻击者，可以提交恶意 URL 来代替正常的 Azure 资源标识符；服务器随后会向该地址发送出站请求，并且用 Microsoft 的话说，“可能会包含其托管身份令牌”——从而把调用方原本绝不应看到的凭据交给它。Microsoft 将该漏洞评为 CVSS 8.8，并将其定级为“重要”，包含修复的包版本为 1.0.2 和 2.0.0-beta.17。该公告记录显示，补丁发布前没有漏洞利用，也没有公开披露，并且没有记录到任何实际危害。此事件是the Orca AI Incident Archive中的一条记录，该档案保存了完整记录及其引用来源、严重性等级和置信度评估。

该公告实际上是怎么说的

微软安全响应中心的记录很简短，而关于此漏洞几乎每一个已公布的细节都源自该记录，或源自微软对少数几个后续问题的回答。完整描述如下：“Azure MCP Server 中的服务器端请求伪造 (SSRF) 允许经过授权的攻击者通过网络提升权限。”CVE 记录于 2026 年 2 月 11 日预留该标识符，并于 3 月 10 日 14:00 UTC 将其公开；微软的发布说明和 NVD 的条目均载明该日期。NVD 分析了该记录，并于当天 18:18 UTC 发布。本文找到的唯一一则监管机构通知来自摩洛哥：DGSSI 下属的 maCERT 部门在日期为 2026 年 3 月 11 日的一份公告中收录了 CVE-2026-26118，将 Azure MCP Server Tools 列为受影响产品之一，并按其自身的风险等级评为“重要”，未给出单独评分，同时附有指向微软发布说明的链接。

该弱点被映射到 CWE-918，即服务器端请求伪造，影响分类为权限提升。Microsoft 的基础评分为 8.8，向量为 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H，时间评分为 7.7，向量为 E:U/RL:O/RC:C——其中 E:U 部分表示设置评分时 Microsoft 尚不知晓存在漏洞利用代码，RL:O 表示已有官方修复程序可用。NVD 采用相同的基础评分并将其归为 High；Microsoft 自己的三步评级将其称为 Important。

有两个字段与评分同样重要。Microsoft 的记录显示 已利用：否，并且 公开披露：否。CISA 在 NVD 条目上的 SSVC 决策记录（时间戳为 2026 年 3 月 5 日）在利用情况上持相同看法——无——同时判定技术影响为 完全、可自动化利用为 否。FIRST EPSS 模型将未来 30 天内被利用的概率估计为约 1.0%，处于第 62.8 百分位，数据提取日期为 2026 年 11 月 3 日。这是一个已被发现并修复的漏洞，而不是已知已被利用的漏洞。

资源标识符如何变成出站请求

Azure MCP Server 是 Microsoft 对模型上下文协议（Model Context Protocol）的实现，这是 AI 代理用来调用工具的接口。其工具接收代理提供的参数——存储账户名称、订阅标识符、数据库名称——并将其转换为针对 Azure 管理平面和数据平面的调用。Microsoft 的文档称，该服务器通过 Entra ID 使用“你的 Azure 用户凭据或托管标识”进行身份验证，其访问权限受 Azure 基于角色的访问控制限制。

这个缺陷出现在这样一个环节：本应指定 Azure 资源的参数反而被当作 URL 接受。微软自己的解释是：攻击者“可以通过向一个接受用户提供参数的 Azure Model Context Protocol (MCP) Server 工具发送特制输入来利用此问题。如果攻击者能够与由 MCP 支持的代理交互，他们就可以提交恶意 URL 来代替正常的 Azure 资源标识符。”随后，服务器会将请求发送到被告知的位置，而不是该工具原本意图指向的位置。

把一个小麻烦变成权限提升的关键，在于随之携带的东西。微软表示，出站请求“可能包含其托管身份令牌”，这使得攻击者能够“无需管理员访问权限”就捕获该令牌。托管身份令牌是一种持有者凭据：任何持有它的人，都可以在令牌过期之前，将其出示给该身份被授权的那些 Azure 服务。同一段落中起到缓解作用的那一半同样重要——攻击者获得的是“与 MCP Server 的托管身份相关联的权限”，用微软的话说，“不会获得更广泛的租户级或管理员权限；仅限于与被攻陷的托管身份绑定的那些权限”。影响范围取决于有人授予了该身份哪些权限，而在实践中，这往往超出单个工具所需的范围。

Microsoft 并未指明受影响的工具或参数，本文所查阅的任何来源也都没有指明。这一省略本身就是一处细节：该公告描述的是一类工具——这类工具接受用户提供的参数，并可能被诱导去抓取某个 URL——而不是单个端点。

修复，以及包含该修复的软件包

这不是 Windows 更新。Azure MCP Server Tools 分别以面向 .NET 的 NuGet 包、npm 包和 PyPI 上的 Python 包形式发布，修复方式是提升部署所用那个包的版本号。Microsoft 的公告列出的受影响范围是：在 NuGet、npm 和 PyPI 各分发渠道中，从 1.0.0 起至 1.0.2（不含）之前，以及从 2.0.0-beta.1 起至 2.0.0-beta.17（不含）之前。

npm 注册表的日期显示，修复后的构建版本在安全公告发布之前就已经出现在注册表上了。@azure/mcp的 1.0.2 版发布于 2026 年 3 月 6 日，比该 CVE 公开早了四天；2.0.0-beta.17 发布于 2026 年 2 月 6 日，比微软预留 CVE 标识符早了五天，比公告出现早了一个月。无论微软内部的先后顺序如何，修补后的代码都不是为回应公开之日而写的。NVD 与 GitHub 的公告数据库在这些上界上是一致的。它们在 PyPI 范围的下端略有出入——NVD 说是 2.0.0-beta.1，GitHub 公告说是 2.0.0b14——这一差异自发布以来就一直存在于这两份记录中，而且只影响 Python 部署需要回溯多远。

该安全公告本身于2026年3月20日——即发布十天后——进行了修订，并附注称 Microsoft“已将相关产品添加到安全更新表中，这些产品记录了用于交付 Azure MCP Server Tools 的各种打包方式。”换言之，公告的第一版只列出了产品名称，却没有列出其发布所经由的每一个渠道；当修复措施是“升级包”而不是“安装此 KB”时，这一点很重要。

什么尚未确立？

是谁发现的。微软的公告和 CVE.org 的记录都没有指明报告者；该 CVE 的致谢字段为空。但这并不能证明没有人获得私下致谢，只能说明不存在公开致谢。

任何利用。Microsoft 记录为零，CISA 的 SSVC 评估也持相同意见，并且本文审阅的任何来源都未描述在野环境中存在身份被入侵的情况。该记录的 real-harm 字段为 false，与此一致。低 EPSS 是一种预测，而非发现，并且没有报告事件并不证明未发生过任何事件。

是否存在公开的漏洞利用代码。 二手报道在此出现分歧。Blueinfy 博客 2026 年 3 月的一篇文章称，存在“公开的概念验证漏洞利用代码，例如 GitHub 上的那些”，并警告会出现“快速武器化”，但未提供链接、载荷或操作说明，也未演示该漏洞。微软的记录称，该漏洞在补丁发布前未被公开披露。2026 年 11 月 4 日，在 GitHub 上按 CVE 标识符搜索仓库，只返回一个仓库——2026 年 3 月 17 日发布的 Microsoft Sentinel 检测实验室，并非漏洞利用代码——而 Mallory 的漏洞页面称，两个候选漏洞利用代码经筛查后被排除。就现有证据而言，关于存在可用的公开漏洞利用代码的说法缺乏依据；关于无人尝试过的说法同样未获证明。

叙事框架。PolicyLayer（一家供应商事件摘要网站）上的一篇文章将 CVE-2026-26118 重新包装为一条未经身份验证的远程代码执行链，最终导致整个租户被接管，并归功于一位具名研究人员和一场 RSAC 2026 演示。该页面自己引用的来源标题却是 SSRF，其日期与 CVE 时间线对不上，而且微软的公告和 SecurityWeek 于 3 月 10 日的报道都没有描述代码执行。本文将以 SSRF 与令牌为核心的叙述视为既定说法，不再重复 RCE 的叙事框架。

为什么关键发现是令牌，而不是请求

服务端请求伪造是 Web 软件中最古老的缺陷类别之一，单就其本身而言，它通常只是一种触及攻击者无法直接寻址的系统的手段。这份记录之所以值得留存，在于随请求一同附带的凭据。MCP 服务器在设计上就是一个混淆代理：它持有某个身份，以便智能体能够代表用户行事；而在服务器看来，智能体传入的每一个参数都是受攻击者影响的文本。当其中某个参数不再是名称、而变成目标地址时，这个代理便会把自己的授权一并带到该目标上。

Microsoft 的文档进一步明确了这种风险集中在哪里。它将本地服务器描述为“严格供你组织内的开发者使用”，同时又单独发布了针对 Microsoft Foundry 和 Copilot Studio 中自托管远程服务器的部署指南——在这些配置中，实际使用的凭据通常是托管标识，而不是开发者自己的登录凭据。该公告所述的令牌窃取路径专门针对托管标识。它并未说明每个安装实例都暴露了，也未说明暴露了多少个。

普遍性教训正是 OWASP 的 AI 安全验证标准如今用这个案例来教授的那一条。AISVS 的编排章节将 CVE-2026-26118 列为其剖析示例之一，并得出结论：“MCP 工具参数必须被视为由攻击者控制，且来自 MCP 服务器的出站请求必须经过与其他任何由智能体驱动的 I/O 所应遵循的相同的出口和来源策略。”这是一项控制建议，而不是关于本次事件的发现，但它是就“应当改变什么”这一问题已发表的最具体答案。

之后发生了什么变化

三件事，而且没有一件是戏剧性的。Microsoft 在三个生态系统中都发布了修复包，并修订了公告以点名这些包。漏洞情报生态系统悄然消化了它：EPSS 分数很低，NVD 记录的最后修改日期是 2026 年 6 月 17 日。标准社区则将其采纳为教学案例，这是一种比补丁更缓慢、也更持久的响应形式。

对于仍在运行受影响版本的用户，修复措施没有变化，也谈不上光鲜：在部署涉及的所有包管理器中，迁移到稳定分支的 1.0.2 或更高版本，或预览分支的 2.0.0-beta.17 或更高版本。除此之外，公告本身的逻辑还隐含了三项控制措施——限制服务器可向外访问的范围，只授予托管身份其工具实际需要的角色，并将任何可能变成 URL 的工具参数视为恶意输入。没有哪一项是躲过 CVE-2026-26118 所必需的。每一项都会降低下一项对攻击者的价值。

档案如何归类这一个

该记录被归类为漏洞——即已发现的事项，而非已知遭到利用的事项——置信度评级为 A，意味着有充分文档记录且一手来源一致，并且未被标记为存在争议。其实害字段为 false，AI 参与情况已确认，因为受影响产品是 AI 代理与云控制平面之间的桥梁，而不是恰好位于附近的通用服务。日期以日精度记录为 2026 年 3 月 10 日，没有结束日期，因为这是一个单一时间点而非一场攻击活动。区域为全球，landmark 标志为 false。

有一个字段的读数与公布的评分不同。该存档的严重性按其自身分级标准记录为 medium；Microsoft 和 NVD 公布的数值都是 8.8，Microsoft 将其称为 Important，NVD 将其归入 High 档。该记录的摘要以这个 8.8 开头，这一差异只是分档方式不同，而非事实不同。

记录无法传达的是，这个故事中有多大一部分是空白。存在一个缺陷，它会把云身份交给任何以错误形式提出请求的人。修复已经存在，并在公告发布前发布。没有署名的发现者，没有具名的工具，没有已确认的利用，外界也无从判断是否有任何托管部署在持有强大身份的同时运行过易受攻击的版本。公告对缺陷的作用描述得很精确，对其他几乎所有事情却保持沉默，而这种沉默正是最值得注意的地方。