证明身份即新攻击面的 Entra ID RCE 漏洞

这一漏洞恰恰印证了核心问题

CVE-2026-69836 是微软 Entra ID 中的一个 CVSS 10.0 严重漏洞。Entra ID 是云身份平台，数百万企业将其视为自身安全边界的核心。一个反序列化漏洞——CWE-502，即业界熟知的未验证对象处理噩梦——允许攻击者在无需任何认证、无需任何用户交互的情况下，在 Entra ID 基础设施上执行任意代码。

正是这种组合将评分推至满分天花板。该漏洞支持远程利用且零前置条件，而这项服务恰恰处于每一个用户凭证与每一个 Microsoft 365 工作负载之间、每一个 Azure 资源之间、每一个连接第三方应用之间。一旦攻击者控制了身份层，就能横向渗透到云工作负载、劫持认证令牌，或重写整个组织的访问策略。

微软最初将此漏洞标记为"正在被利用"。最新更新说明称威胁已有所平息——该漏洞目前未在野外被利用——但核心发现依然成立：修复措施在披露之前就已由微软方面部署，且没有任何面向客户的补丁、没有 KB 文章、没有任何需要用户自行配置的修改项。

这正是云 CVE 的新常态。你不需要打补丁。微软帮你打了。你需要做的是判断在发现到修复之间的窗口期内，是否有人尝试利用它。

问题的设计根源

这里的叙事远不止一个 CVE 那么简单。它关乎这样一个事实：当你的安全架构围绕单一集中式身份服务构建时，最终你会发现——这个服务本身确实只是众多服务之一，与任何其他应用堆栈一样存在同类软件缺陷。

Entra ID 的设计初衷是简化访问管理：单点登录、条件访问策略、特权角色分配、令牌签发。而这种简化恰恰也是该漏洞在结构层面如此危险的原因。每个通过 Entra ID 进行认证的微软租户、每个 Azure 订阅、每个信任 Entra 作为身份提供商的第三方 SaaS 集成——它们都共享同一个后端。一次成功的入侵不会局限于某个范围，它会级联扩散。

这正是零信任架构的根本性张力所在。你可以在监控仪表板上把微分段和最小权限访问说得头头是道，但如果身份层本身就是一个存在可利用反序列化端点的单点故障，你并没有消除边界。你只是让它变得更加集中。

通过协调披露渠道报告该漏洞的安全研究员罗伯特·费兹帕特里克（Robert Fitzpatrick）找到的，正是一切反序列化漏洞调查最终都会发现的画面：一个接受未信任数据但未做充分验证的输入路径。修复已在微软基础设施层面完成。但那个架构层面的问题仍未得到解答。

防御方真正应该做什么

没有可部署的补丁。这意味着微软给出的修复建议介于"毫无帮助"和"发人深省"之间。该公司建议审查 Entra ID 登录日志、条件访问策略以及特权角色分配，查找早于修复部署之前的异常活动迹象。“审查”，而非"打补丁"。“寻找迹象”，而非"止血"。

这正是云服务漏洞的运营现实。你的安全团队无法决定修复何时上线。时间线由微软决定。你的团队能做的是回溯到足够细的粒度，以确定暴露窗口期是否产生了实际入侵。

在实操层面，这看起来是这样的：拉取补丁部署前的 Entra ID 登录日志，寻找与基线不符的模式——来自异常地理区域的失败认证尝试、来自意外应用的令牌请求、超出正常变更节奏的条件访问策略修改、授予给原本无权限账号的特权角色分配。这些是在一个你无法控制的系统中，猎杀入侵证据时真正值得关注的事项。

更广泛的建议同样重要：加强对身份基础设施整体的监控力度。认证服务中的反序列化缺陷不会消失。它们之所以持续成为高影响目标类别，正是因为收益与之成正比——掌控身份层，就意味着掌握了一切下游系统的杠杆。

透明度倡议改变了什么？

微软将此披露纳入其"迈向更高透明度"（Toward Greater Transparency）云服务商漏洞倡议框架下。这一意图值得肯定：不再将后端修复视为隐秘事件，而是让客户了解那些影响了其环境的威胁。此前，许多云服务 CVE 未被报告，原因很简单——客户那边没什么需要去修补的。

透明度不等于韧性。知道自己曾有一段时间处于暴露状态，并不会让你更安全。它只让你更清楚地知道自己曾经不安全。这一倡议是走向问责的一步，但它并未改变根本性的不对称格局：微软掌控修复时间线、披露时间线，以及你的团队在调查潜在入侵时的所有证据来源。

那些将 Entra ID 视为可信基石而非与其他服务同样存在漏洞面的普通组件的组织，此刻正在面对现实冲击。身份基础设施是软件。它有 bug。它会被利用。从基于边界的转向基于身份的安全模型，原本旨在降低爆炸半径。而这个 CVE 证明，将信任集中于单一系统反而起到了相反的效果——它放大了风险。

接下来会发生什么

漏洞本身已经修复。微软最初确认的野外利用行为已停止。但架构层面的教训，才刚刚开始在整个安全社区中产生回响。

每个以 Entra ID 作为控制型身份层来构建零信任叙事的企业，现在都必须回答一个从未预料到的问题：当身份服务本身成为攻击目标时，会发生什么？答案显而易见——要么分散你的身份依赖，要么接受你的安全架构中存在一个你无法控制的灾难性单点故障。

两条路都不好走。分散化意味着管理多个身份提供商、重新协商信任关系、重建条件访问策略。接受则意味着带着风险继续生存，并大量投入检测能力建设——而这恰恰正是微软现在要求所有人用登录日志和政策审计去做的事情。

这个漏洞终会从头条新闻中淡出。它所暴露出的结构性问题，不会。