一个 10.0 分的漏洞出现在企业搭建智能体的平台上，说明失分点常常不在模型能力，而在最基础的身份认证。据 IT Security News《Microsoft Fixes Critical Azure AI Flaw Rated CVSS 10.0》报道，微软已修复 Azure AI Foundry（又称 Microsoft Foundry）一处最高严重级漏洞，编号 CVE-2026-85889，通用漏洞评分系统（Common Vulnerability Scoring System，CVSS）评分 10.0。结论先给：该漏洞源于关键功能缺失身份认证，目前没有证据表明已被真实攻击利用；微软已完成云端修复，并称受影响云服务已完全缓解，客户无需采取任何操作。同期还有三枚评分 9 分以上的云漏洞被一并处置。
满分从哪来：一个关键功能缺了身份认证
一条漏洞能拿满分，往往不是利用手法有多花哨，而是因为它把最外层的门槛直接拿掉了。CVE-2026-85889 的成因写明是「关键功能缺失身份认证」（missing authentication for a critical function）。缺失认证意味着发起方不需要账号、凭据或任何前置交互，经网络即可尝试提升权限，并可能触达敏感资源或管理功能。
把它放回产品语境里看会更清楚。Azure AI Foundry 是企业级平台，用于构建、部署和管理生成式 AI 应用与自主智能体（autonomous agents）。平台在认证环节留出缺口，受影响的就不只是某一次推理请求，而是同一环境里智能体可调用的工具、可访问的数据、可触发的流程，这也是它被评为最高严重级的原因。
该漏洞由安全研究员 Rémy Marot（社交媒体账号 @R_Marot）发现并上报。利用现状需要单独说清：目前没有证据表明该漏洞已被真实攻击利用。微软已完成云端修复，并称受影响云服务已完全缓解，客户无需采取任何操作。
从评分逻辑看，认证类缺陷之所以容易触顶，是因为它同时满足两个条件：可远程发起，且不需要任何前置凭据。这类缺陷一旦被利用，攻击者拿到的是平台的信任位置，而不是某一个具体的数据点。
换一句更直白的话：模型可以被替换，认证不能被跳过。企业选择云上 AI 平台的默认假设，是平台会把基础安全做好；这次披露说明，默认假设也需要定期验证。
- 成因归类：关键功能缺失身份认证，属认证类缺陷，而非模型或推理层缺陷。
- 利用条件：无需凭据，可经网络发起，前置门槛低。
- 潜在影响：未授权攻击者可能提升权限，触达敏感资源或管理功能。
- 处置状态：云端修复完成，受影响云服务已完全缓解，客户无需操作。
- 利用现状：暂无已被真实攻击利用的证据。
同批修复的三枚高危漏洞：高分区集中在模型之外的支撑层
与 CVE-2026-85889 同期处置的，还有三枚评分 9 分以上的云漏洞。它们的共同点很清晰：出事的地方都不在模型本身，而在围绕模型搭建的认证、授权、输入处理与数据层。
| CVE 编号 | 受影响产品 | 漏洞类型 | CVSS 评分 |
|---|---|---|---|
| CVE-2026-85885 | Microsoft 365 Copilot | 命令注入（command injection） | 9.9 |
| CVE-2026-85878 | Azure Database for PostgreSQL | 授权不当（improper authorization） | 9.9 |
| CVE-2026-87701 | Azure Cosmos DB | 中和处理不当（improper neutralization） | 9.6 |
四枚漏洞放在一起看，可以得到一个对工程侧更有用的判断：高分漏洞的分布，比漏洞数量本身更能说明问题。Copilot 对应交互与指令入口，PostgreSQL 对应业务数据存放层，Cosmos DB 对应智能体常用的状态与记忆层，Azure AI Foundry 对应智能体的编排与管理平面。这条链路上一旦有一环缺少认证或授权校验，上层做过多少模型层面的加固都会被绕开。
对使用云上 AI 平台的团队来说，这次披露的价值不在「有没有被攻击」，而在「哪些位置会被判定为最高严重级」。身份认证属于最基础的控制项，也最容易被默认成「平台已经做好」而不再自查。
三类缺陷其实指向同一个问题：边界控制。缺失身份认证回答不了「你是谁」，授权不当回答不了「你能做什么」，中和处理不当回答不了「送进来的输入是否安全」。放在智能体场景里，这三道题需要平台与使用方共同回答，因为智能体的每一次工具调用，都是一次真实的凭据使用。
给一线从业者的三条自查动作
下面三条只涉及通用工程常识，不依赖任何特定产品的功能，可以今天就排进日程。
- 清点对外可达的智能体入口：把每一个可能被外部触达的端点列成清单，逐个确认请求进入业务逻辑之前是否已有认证前置；只对内部网络开放的入口单独标注，避免两类混在一起。
- 做一次无凭据访问验证：在不携带任何凭据的前提下向入口发起请求，观察返回是拒绝还是数据。这类验证只在自己拥有书面授权的环境里执行，测试范围事先写清。
- 把权限边界画清楚：智能体可调用的工具、可访问的数据源、可触发的管理操作分别列出，按最小权限收敛，同时保留可追溯的调用日志，便于事后复盘。
这三步做完，团队至少能把「平台上有什么、谁能碰到什么」讲清楚。认证缺口的麻烦之处在于它不需要高深技巧就能被利用，而治理它的方法同样不复杂，只是需要有人真正核一遍，并把核过的结论写下来。
把自查做成可重复的动作，比做一次性排查更有价值：将入口清单、无凭据验证结果与权限边界表并入发布前的检查模板，每次新增入口时重新核一遍。这样在漏洞披露之后，团队能快速判断自己是否落在受影响范围内，而不必等平台方给出清单。
常见问题
CVE-2026-85889 会被实际利用吗？
目前没有证据表明该漏洞已被真实攻击利用。评分 10.0 描述的是漏洞本身的严重程度，而不是已被攻击的事实。微软已完成云端修复，并称受影响云服务已完全缓解。
使用 Azure AI Foundry 的团队现在需要做什么？
按微软的说法，受影响云服务已完全缓解，客户无需采取任何操作。建议把这次披露记入内部安全台账，并对照上文的入口清单做一次自查，确认自身业务侧的认证前置没有被遗漏。
为什么身份认证缺口比模型能力更值得警惕？
模型能力决定业务上限，身份认证决定安全底线。缺失认证的漏洞无需凭据即可经网络尝试利用，前置条件极少；而模型层面的能力再强，也无法弥补入口处不校验身份的缺口，这也是它在评分体系中拿到满分的原因。
参考来源
- IT Security News.《Microsoft Fixes Critical Azure AI Flaw Rated CVSS 10.0》2026
