The identity plane that most of the enterprise world stands on just carried a maximum-severity remote code execution flaw — and the entire lifecycle of the bug, from discovery to remediation, happened somewhere customers could not see. Microsoft has patched CVE-2026-69836, a CVSS 10.0 deserialization-of-untrusted-data vulnerability in Entra ID that allowed unauthorized attackers to execute code over the network, per The Hacker News.
A 10.0 in the identity control plane
Entra ID is not another application in the portfolio; it is the control plane that authenticates the rest of the portfolio. A pre-auth remote code execution path in that layer is about as severe as a cloud vulnerability gets, which the maximum CVSS score reflects. The flaw was found internally — credit goes to Robert Fitzpatrick, a principal security engineer at Microsoft — and, because Entra ID is a fully managed service, Microsoft fixed it server-side. The company’s guidance states there are no additional actions customers need to take.
For defenders, that is genuinely the good news. There is no patch window, no exposed fleet of unpatched tenants, no scramble. The service was mended above everyone’s heads.
The ‘exploited’ flag that flipped
The uncomfortable part is what happened around the disclosure. Microsoft’s advisory initially marked the vulnerability as exploited in the wild. After The Hacker News contacted the company, Microsoft corrected the field on August 21 and stated that the flaw “was not exploited in the wild.”
Either state of that flag is plausible; what matters is that customers had no independent way to check. In an on-premises world, a defender can hunt for indicators, review logs, and form their own view of exposure. When a CVSS 10.0 lives and dies inside a provider’s managed service, the only available facts are the ones the provider publishes — and in this case the published facts changed.
What this means
For practitioners, this incident is less about one bug and more about the shape of SaaS-era identity risk. Three takeaways are worth carrying into your next architecture review. First, treat your cloud IdP as critical infrastructure operated by someone else: the residual risk is real even when your patching burden is zero. Second, push for contractual and technical transparency — tenant-scoped telemetry, audit-log completeness, and clear provider commitments about post-incident disclosure — because advisory metadata, as this case shows, can be revised after the fact. Third, keep compensating controls in your own hands: conditional access hardening, workload identity hygiene, and continuous monitoring of token issuance patterns are the parts of the identity plane you can still observe directly. A perfect-10 that requires no action from you is a gift, but it is also a reminder of how much of your security posture now lives behind someone else’s vault door.
