Azure OpenAI 中的 SSRF：当托管 AI 服务沦为权限提升的中继

这是什么？

2026 年 7 月 2 日，微软就 Azure OpenAI 中一个严重的服务端请求伪造（SSRF）漏洞发布了安全公告。Azure OpenAI 是微软在 Azure 平台内运行 OpenAI 模型（包括 GPT 系列）的云托管服务。该漏洞在 CVSS 3.1 评分中被评为 9.9，归类为权限提升问题。根据微软以及 CrowdStrike 的 2026 年 7 月补丁星期二分析，该漏洞已在微软自有基础设施上完全修复，服务的客户无需应用任何补丁。

这一发现的价值，与其说在于即时风险（服务端已修复），不如说在于它所揭示的道理：即使是完全托管的 AI 平台即服务，也会继承困扰云应用长达十年的同类 Web 请求处理弱点。这是一个关于漏洞类别的防御性案例研究，而非可直接利用的攻击。

工作原理

当一个服务被诱导向攻击者指定的目标发起网络请求时，就会发生服务端请求伪造。在托管 AI 服务中，请求处理面异常宽广：平台经常获取用户提供的 URL，用于摄取供检索的文档、拉取多模态提示所需的图像，或回调工具与函数端点。只要目标地址没有得到严格校验，其中任何一条代码路径都可能成为 SSRF 的落点。

根据 NVD 条目（CWE-918），该漏洞需要一个经过身份验证的低权限攻击者（PR:L），无需用户交互（UI:N），攻击复杂度低（AC:L），并且——关键之处——具有变更的作用域（S:C）。正是这一作用域变更把评分推高到 9.9：脆弱组件能够作用于超出自身安全边界的资源。实际上，云服务内部的 SSRF 允许攻击者从该服务向未暴露于互联网的内部端点发起请求——内部管理 API、相邻服务，或发放身份令牌的实例元数据端点。从可信位置触达这些内部面，正是请求伪造漏洞演变为权限提升的途径。目前未公开任何概念验证，微软也未披露确切的注入点。

为何重要

企业越来越把托管 AI 端点视为置于网络核心的可信基础设施，并通过托管身份连接到私有数据存储。这种信任恰恰就是问题所在。当 AI 服务本身可被操纵去发起内部请求时，它的网络位置及其被赋予的身份就成了攻击者的，而不再是你的。SSRF 的影响范围，由被攻陷服务被允许触达的一切来界定。

此案提醒人们：「责任共担」的界线会移动，但从不消失。这个具体漏洞归微软所有，也由微软修复。但其架构层面的教训——AI 服务的出站请求能力本身就是一等攻击面——适用于你自行运营的每一台自托管推理服务器、网关和 RAG 摄取管线，在那里没有任何厂商会悄悄为你修补。

防御措施

面向任何运营会获取外部内容的 AI 服务的具体、非侵入式加固：

• 锁定出站流量。 摄取与工具调用组件只应触达一份明确的目标白名单。对出站流量采取默认拒绝，并在网络层阻断私有网段（RFC 1918）、链路本地地址以及元数据端点（169.254.169.254）。
• 保护实例元数据。 强制使用类似 IMDSv2 的会话绑定令牌（或你所在云的等效加固方案），使单纯的 SSRF 无法窃取身份凭据。
• 将托管身份收紧到最小权限。 为每个 AI 工作负载赋予其所需的最窄角色与资源范围；被盗身份的危险程度仅取决于其权限。
• 校验并重新解析 URL。 拒绝非 HTTP 协议，在校验后对主机名进行规范化并重新解析以挫败 DNS 重绑定，切勿跟随指向内部空间的重定向。
• 租户隔离与监控。 按租户切分网络路径，并记录服务的出站请求；异常的内部目标是高信号的 SSRF 指标。

落实这些控制，能让你自有技术栈中的 SSRF 以「失败即关闭」的方式收场，而不是成为通向云控制平面的跳板。

状态

项目	详情
受影响产品	Azure OpenAI（云托管服务）
弱点类别	服务端请求伪造（CWE-918）
严重性	CVSS 3.1 基础分 9.9（严重）——向量 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
披露	2026 年 7 月 2 日（微软公告 / NVD）
修复	已在微软基础设施上完全缓解；无需客户操作
公开利用	截至撰稿时未知
参考	CVE-2026-45499