Azure SRE Agent:一项多租户令牌校验让陌生人围观您的故障处置(CVE-2026-32173)
2026 年 4 月 20 日披露:Azure SRE Agent 的 /agentHub WebSocket 上 Entra ID 应用注册的多租户配置失误,让任意租户都能接入并静默旁听每条提示词、推理步骤、CLI 命令和凭据。
这是什么?
2026 年 4 月 20 日,Enclave AI 的 Yanir Tsarimi 发表了《How We Could Watch Your Azure SRE Agent In Real Time》,作为 CVE-2026-32173 的公开披露文章 —— 这是 Microsoft Azure SRE Agent 中的一个信息泄露漏洞。该 CVE 最初在 2026 年 4 月 2 日发布,CVSS 评分为 8.6,分类为 CWE-287(身份认证不当)。Microsoft 安全响应中心确认了漏洞,将其评为严重级别,并在服务器端完成修复;在正式可用版本中使用该产品的客户无需采取任何操作。
漏洞出现在两项常见工程决策的交叉点:一个用于推送 AI agent 活动的 SignalR WebSocket hub,以及一个被配置为 multi-tenant(多租户)的 Entra ID 应用注册。单独看,两者都不存在问题。组合在一起且缺少租户校验时,它们让每一个活跃的 Azure SRE Agent 实例在 Microsoft 修复之前一直处于跨租户静默旁听的风险中。
工作原理
Azure SRE Agent 于 2026 年 3 月 10 日正式可用(GA)。它是 Microsoft 的常驻运维 agent:连接到一个 Azure 环境后,会监控告警、诊断故障、执行 Azure CLI 命令、重启服务,并与 PagerDuty 和 ServiceNow 集成。为了让所有这些活动对人类可见,agent 通过一个名为 /agentHub 的 WebSocket 端点推送每一个事件 —— 用户提示词、模型回复、内部推理链、带参数的工具调用、工具输出 —— 该端点位于 Azure SRE Agent Gateway 上,以 SignalR Hub 的形式提供服务。
Hub 通过 bearer token 控制入站连接。验证逻辑检查了 签名 和 受众(audience),而这两项,任意租户中的任意 Entra ID 账号都可以针对一个多租户应用注册生成。缺失的是两项校验:
# Hub 实际验证的内容(示意 —— 仅作说明,非攻击代码)
token_signature_valid # ✅
audience_matches_app # ✅
# Hub 未做的校验
caller_tenant == target_agent_tenant # ❌
caller_has_role_on_resource # ❌
WebSocket 连接建立后,hub 不再按调用方身份过滤事件,而是将每一个事件广播给每一个已连接的客户端。要加入某个目标的事件流,只需要该 agent 的 子域名 —— Enclave 描述其为”可预测且可枚举” —— 以及大约 15 行 Python 代码,用于向 login.microsoftonline.com 获取 token 并连接到该 SignalR hub。
接入后看到的会话记录包含:用户的提示词、agent 的回复、agent 的私有推理链、每一次 CLI 调用及其完整参数、命令输出。在 Enclave 自己的测试中,这些输出包含了生产 Web 应用的部署凭据。受害租户侧不会留下任何痕迹;唯一的记录存在于攻击者的终端中。
为什么重要
从这次披露能看出三层比 CVE 本身更深远的教训。
第一是结构性问题。在 Entra ID 之上挂载 SignalR hub 并不是什么稀奇做法。这里的错误属于多租户 SaaS 已经存在了十年的同一类授权混淆模式 —— 有效 token ≠ 已授权用户 —— 只是被搬到了价值更高的数据流上。任何为 AI agent 接上实时通道的团队都会继承同样的风险面。
第二是可观测性。AI agent 的设计本身就在聚合状态:工单、监控面板、密钥仓库、部署流水线、推理链 —— 这些原本是分散在不同端点的内容。当一个通道把这种聚合暴露出去时,影响半径是 该 agent 曾经接触过的一切,且已经被模型为攻击者综合好了。普通 API 泄露会丢一个端点的数据,agent 泄露会丢失模型的整个世界观。
第三是受害方一侧缺乏遥测。租户既无日志可圈定暴露范围,也无信号可在事后调查。对于运维生产环境的 AI agent 而言,“谁在订阅这条数据流”已不可再省略。
防御
由此次披露直接派生出的具体行动。
如果您在预览窗口期(3 月 10 日至服务器端修复之间)运行过 Azure SRE Agent,请将该时间段视为可能被暴露:轮换可能出现在 agent 会话或 CLI 输出中的凭据和密钥,并复查 agent 当时可访问的配置数据。
对于任何自研的、通过 WebSocket/SignalR/SSE 推送活动的 agent,请在 hub 自身完成 租户校验 与 授权校验,而不仅仅是验证 bearer 的签名。将 tid claim 和资源 ACL 视为客户端被加入任何分组之前的强制检查。除非多租户是产品的明确需求,否则将应用注册标记为单租户;当确实需要多租户时,显式编写租户隔离逻辑。
对 SignalR 本身,使用以租户 ID 或资源 ID 为键的 groups,并在 OnConnectedAsync 中添加授权过滤器。对其 claim 中不包含目标资源角色的连接予以拒绝。在威胁建模中,把 hub 视作和其他任何 API 表面同等重要的对象。
把 AI agent 的会话记录视为可审计的一等公民。按订阅者粒度向安全日志发送事件,把该日志开放给客户租户,对异常订阅者发出告警。Azure SRE Agent 受害方无法看到旁听者这一点,正是把”授权 bug”放大为”静默事件”的关键缺陷。
最后,在威胁模型里把 agent 当作 凭据传输通道。如果 agent 需要读取密钥才能完成工作,那么暴露其执行痕迹的每一个通道都属于密钥处理通道,应按对应等级分类管理。
状态
| 项目 | 详情 |
|---|---|
| CVE | CVE-2026-32173 |
| CVSS | 8.6(HIGH) |
| CWE | CWE-287(Improper Authentication) |
| 公布(NVD) | 2026 年 4 月 2 日 |
| 公开披露文章 | 2026 年 4 月 20 日(Enclave AI) |
| 受影响组件 | Azure SRE Agent Gateway,/agentHub SignalR Hub |
| 产品 GA 时间 | 2026 年 3 月 10 日 |
| 修复 | 服务器端,由 Microsoft 完成。客户无需操作。 |
| 报告者 | Yanir Tsarimi,Enclave AI |
Sources
- → https://enclave.ai/blog/anyone-could-watch-your-azure-ai-agents-conversations-in-real-time
- → https://nvd.nist.gov/vuln/detail/CVE-2026-32173
- → https://github.com/advisories/GHSA-85hw-hqj5-m956
- → https://www.csoonline.com/article/4161389/azure-sre-agent-flaw-let-outsiders-silently-eavesdrop-on-enterprise-cloud-operations.html
- → https://www.sentinelone.com/vulnerability-database/cve-2026-32173/