Azure SRE Agent 的 9.9 授权漏洞本可让调用者继承其身份

CVE-2026-62830 是 Azure SRE Agent 中的一个权限缺失漏洞。Azure SRE Agent 是微软为 Azure 站点可靠性团队打造的 AI 驱动代理，用于对事件进行分级、查询遥测数据，并在配置允许时执行修复。微软于 2026 年 8 月披露该漏洞，并根据 CVSS 3.1 标准将其评为 10 分制中的 9.9 分——严重级别。任何运行该代理的 Azure 租户都受此漏洞影响；事件档案中未记录有已确认的受害者，也未发现漏洞利用情况。微软对该漏洞的描述只有一句话：“Azure SRE Agent 中的权限缺失允许经授权的攻击者通过网络提升权限。”该服务已在服务器端完成修复，微软表示客户无需修补任何内容。包含严重性和置信度评级的完整条目位于Orca AI Incident Archive，与本系列中的相邻事件并列记载。

微软公布了什么，又遗漏了什么

微软针对 CVE-2026-62830 的《安全更新指南》条目记录了 Azure SRE Agent 中的一处权限提升漏洞，弱点类别为 CWE-862（缺少授权），基础评分为 9.9，时间评分为 8.6。其向量 — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C — 描述了一种网络攻击：仅需低权限、无需用户交互，并会造成高机密性、完整性和可用性影响。微软在公告的致谢部分将该发现归功于 Offensi 的安全研究员 wtm。

该向量的两部分说明了关键情况。范围指标为 Changed (S:C)，微软自己的指标文档将其定义为漏洞组件与受影响组件不同、且由不同安全主管机构管理的情况。时间指标为 Unproven exploit code、Official fix 和 Confirmed，因此时间评分低于基础评分。

该公告的常见问题解答解释了为何存在 9.9 的评分却没有下载链接：“Microsoft 已完全缓解此漏洞。此服务的用户无需采取任何操作。此 CVE 的目的是提供进一步的透明度。”Microsoft 将该产品标记为完全托管服务，因此该条目没有内部版本号，也没有受影响版本范围。

可利用性表就像 FAQ 一样清楚。公开披露：否。已被利用：否。利用性评估：不太可能。公告没有描述的是代表流、托管标识或运行手册。它也没有给出受影响版本范围：CPE 只写了产品而没有版本，列出的唯一受影响版本是一个短横线。读者想了解的关于该机制的一切都必须来自别处，而那个别处主要是存档自身的条目。

智能体是什么，以及为什么它的身份才是真正值得抵达的东西

Azure SRE Agent 并非硬附加到仪表板上的聊天机器人。Microsoft 的 Azure SRE Agent 文档描述了一种代理：它可连接 Azure 资源、可观测性工具、事件平台和源代码仓库，收集信号、关联部署、提出缓解措施，并且——取决于客户设置的运行模式——执行这些措施。在 Review 模式下，由管理员批准写入操作；在 Autonomous 模式下，代理无需等待即可应用这些操作。它的能力可通过技能和 Runbook、Azure CLI 操作、自定义代理、Python 工具、MCP 连接器和代理挂钩得到扩展。

同一份文档道出了让这个 CVE 变得有意思的事实：“该代理使用托管标识进行身份验证，并在 Azure 基于角色的访问控制（RBAC）下运行。”托管标识是分配给某一服务的 Entra 标识，它能做什么，完全取决于其角色分配所允许的范围。因此，该代理的权限并不是代理代码本身的属性，而是附加到该标识上的角色所赋予的——而这恰恰是缺失的授权检查无法守住的边界。

一篇单独的技术文章，即 HackTricks Cloud 中关于 Azure SRE Agent 权限提升的条目，描述了该问题的结构性版本，但没有引用 CVE-2026-62830。该条目列出了一系列控制平面操作，使调用者能够操纵代理——打开线程、批准提议的修复、重新绑定代理配置、重新指向数据连接器——并将结果描述为混淆代理：调用者不需要代理的权限，只需要一种让代理使用这些权限的方法。该条目并非关于此 CVE，不应被解读为其佐证。它之所以有用，原因与评分相同：它显示了权限实际归属何处。

机制：档案所描述的内容，以及供应商所确认的内容

该归档条目将这一漏洞描述为其所谓的 Scope-Changed OBO（on-behalf-of）流程中的失效。on-behalf-of 流程是一种令牌交换：其中一项服务将调用方的凭据换取一个令牌，使其能够以该调用方的身份调用下游服务。该归档称，如果该交换处的授权检查失败，下游调用就可以回退到代理自身的作用域限定于租户的托管标识，而不是调用方的身份。一个权限较低但已通过身份验证的调用方随后会继承代理的服务主体权限，并可能修改 Runbook、遥测数据和基础设施——不仅是该代理，还包括该托管标识持有角色的每一个 Azure 资源。

该描述与 Microsoft 已发布的所有内容相符，但它并不在 Microsoft 发布的内容之中。厂商的文本确认了三点：缺少授权检查，调用方只需要低权限，并且影响跨越了安全权限边界。它没有确认令牌交换、身份继承，或运行手册与遥测示例。存档条目是这些内容的来源，而存档是次级数据集，不是厂商。

关于 OBO 流程与影响范围的标题，出现在不止一个地方：同一段文字在 forkast.news 和 Yahoo Tech 等平台上同步刊发。这种联合发布使该报道只算一个来源，而非多个来源。就本文所核查的媒体而言，没有任何一家发布过自己的遥测数据、概念验证，或对该机制的复现。

哪些是已确立的，哪些是被描述的，以及哪些是从未被主张的

档案馆将这条记录评为 A 级——文献记载充分，原始来源彼此一致——并且没有将其标记为有争议。它没有记录任何现实世界中的伤害。该评级针对的是记录的核心事实，而这些事实在各来源之间确实一致；这并不表示条目中的每一句话都已得到独立复现。

• 由供应商确认。 CVE-2026-62830 影响 Azure SRE Agent，属于 CWE-862 缺少授权，CVSS 3.1 基础评分为 9.9、时间评分为 8.6，无需客户采取操作，未公开披露，且未被记录为已利用。

• 由独立安全报告与信息补充共同确立。Cisco Talos 的 2026 年 8 月补丁星期二汇总列出了该 CVE，其 CVSS 评分同为 9.9，且同样存在缺少授权的弱点，并将其归入 Microsoft 的“较不可能”利用评估。通过 NVD 记录的 CISA SSVC 评估将利用情况评为无、可自动化评为否、技术影响评为完全。OpenCVE 的信息补充列出 EPSS 得分为 0.00778，并记录该 CVE 不在 CISA 的已知利用漏洞目录中。

• 已描述，但未经独立确认。OBO 令牌交换失败、代理的托管标识的继承，以及运行手册、遥测和基础设施方面的后果，来自档案条目和联合供稿的二次报道。微软的公告并未点名提及这些内容。它们是记录中最有用的部分，也是其中记载最少的部分。

• 任何地方都未证实。没有利用、没有受害者、没有公开的概念验证、没有内部版本号，也没有受影响版本范围。微软的可利用性一栏——公开披露：否，已被利用：否，可能性较低——是现有最接近状态报告的东西。

• 主流报道缺失。 在一般科技和安全媒体中搜索该 CVE，The Register、BleepingComputer、SecurityWeek 或 Help Net Security 均未返回任何文章。其公开足迹仅限于供应商公告、漏洞数据库、一篇 Patch Tuesday 综述以及那篇联合供稿文章。对于 9.9 而言，这很不寻常；这是关于记录本身的事实，而不是对风险的判断。

修复，以及比修复本身更持久的检查

由于 Azure SRE Agent 是一项托管服务，因此修复是在 Microsoft 一侧应用的。无需安装任何更新，也没有可用于与资产清单进行比对的内部版本号，客户也无法从外部确认某个租户在特定日期之前是否受到了保护。Microsoft 的立场是无需采取任何操作，而就该漏洞本身而言，这一立场是正确的。

该存档条目补充了公告中并未明确说明的指导：审计托管标识分配，依据智能体实际需要审查 RBAC，并监控异常的权限提升。该指导来自存档，并非 Microsoft 的引述。

实际的后果源自架构本身，而非任何来源的建议，因此应将其视为推断。如果智能体的权限就是它的角色分配，那么持久有效的控制手段便是这些分配的适用范围，以及保留那些能够显示其被使用情况的控制平面日志。服务端的修复会关闭该路径；但它不会追溯性地收窄一个被过度授权的托管标识，也无法帮助一个没有保留日志的组织。在 CVE 关闭之后，这两件事仍然由客户自己负责。

它在2026年8月批次中的位置

塔洛斯（Talos）的汇总让这一对比无法回避。当月，该汇总还列出了 Copilot Cowork 中的 CVE-2026-59118——因授权不当导致的权限提升，评分 9.3；以及 Azure SQL Database 中的 CVE-2026-56162——权限提升，评分 10.0。塔洛斯报告称当月已在野利用的那一个漏洞并非上述任何一个：而是 Windows AFD for WinSock 中的 CVE-2026-68820。塔洛斯清单中涉及 AI 产品的条目都是授权类缺陷，而这正是本记录所记载的风险的具体形态。

这些都不能使 CVE-2026-62830 成为一起入侵事件。它是一个针对已修复服务的透明度 CVE，公开发布是为了让客户看到哪里出了问题，并检查自己的配置。该记录的价值在于它留下的配置问题——代理身份能够触及哪些资源，以及是否有人会注意到它被使用——而不是一个需要排期的补丁。