A Perfect 10: Inside Microsoft's Critical Entra ID Flaw and What It Means for Cloud Identity

A CVSS score of 10.0 is the maximum possible severity rating a vulnerability can receive. Microsoft's disclosure of CVE-2026-69836, a flaw in its Entra ID identity service, hit that ceiling. For any organization that relies on Entra ID to control who can access what, and most enterprises now do, it's worth understanding what happened and why it matters even though Microsoft says there is nothing left for customers to do.

What the flaw actually was

Microsoft's advisory describes the issue as insecure deserialization: a case where Entra ID converted untrusted, attacker-supplied data into active internal objects without validating it first. That category of bug, tracked generally as CWE-502, is one of the more dangerous classes of vulnerability that exists, because it can let an attacker's input effectively become executable logic inside the target system.

In this case, the combination was severe enough to earn a perfect score: the flaw was exploitable remotely, required no special privileges, needed no user interaction, and, if exploited, could have given an attacker full control over confidentiality, integrity, and availability of affected systems. In plain terms, an outside attacker with no existing access could potentially have executed code inside Microsoft's cloud identity infrastructure.

Who found it, and what happened after

The vulnerability was identified by a Microsoft security engineer, and Microsoft patched it on its own infrastructure before public disclosure, which is why the company describes it as fully mitigated with no customer action required. Because Entra ID is a cloud service Microsoft operates directly, the fix could be deployed centrally rather than through updates that individual organizations needed to install.

The disclosure had one notable wrinkle: Microsoft's advisory briefly listed the flaw's "Exploited" status as "Yes" before correcting it to "No" after outside researchers questioned the entry. Microsoft says the vulnerability was not exploited in the wild, and the correction appears to have been a documentation error rather than a reversal of the underlying facts.

Why "already fixed" doesn't mean "nothing to learn"

It's tempting to treat a vendor-side, fully patched cloud vulnerability as someone else's problem. That misses the real lesson. Identity services like Entra ID sit at the center of modern access control: they decide who can log in, what they can reach, and which systems trust which other systems. A maximum-severity flaw in that layer means the potential blast radius, had it been found by an attacker first, would have extended into every downstream system that trusts Entra ID for authentication.

That risk profile is not unique to Microsoft. Any organization relying on a cloud identity provider, whether that's Entra ID, another major identity platform, or a homegrown system, is trusting that provider's security engineering as much as its own. A few practical takeaways apply regardless of which provider you use:

• Track identity-provider advisories directly, not just your own patch cycles. Vendor-side fixes to cloud services can close a hole before you even know it existed, but only if you're paying attention to what was fixed and why.
• Apply least-privilege principles even to "trusted" internal traffic. A flaw like this is dangerous precisely because deserialization vulnerabilities can bypass normal authentication checks; systems that assume anything reaching them is already trusted are more exposed.
• Ask vendors how they discover and disclose flaws in centrally-hosted services. Microsoft credits an internal engineer here; understanding whether your identity provider has a mature internal security research function is a reasonable question to ask during procurement or renewal.
• Don't conflate "patched" with "never happened." A CVSS 10.0 flaw existing in production, even briefly and even if never exploited, is worth factoring into your own risk assessment of that dependency.

Most organizations now depend on their identity provider the way they once depended on their network firewall. This disclosure is a reminder that the systems doing that job deserve the same scrutiny, even when the vendor tells you there's nothing left to do.