August 21, 2026. CVSS 10.0. Deserialization. Microsoft patched a remote code execution vulnerability in Entra ID, its cloud identity service — and told customers to do nothing. The flaw, CVE-2026-69836, is rated CVSS 10.0, the maximum score, and stems from the deserialization of untrusted data that let an unauthenticated attacker execute code over the network.

The line to remember is not technical. It sits in Microsoft’s advisory: “This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take. The purpose of this CVE is to provide further transparency.” An invisible patch, for a flaw nobody can verify.

The flaw at the heart of identity

Entra ID — formerly Azure Active Directory — is the service that authenticates logins and controls access to Microsoft 365, Azure, and thousands of connected third-party apps. It is the central identity component at the vast majority of enterprises.

Deserialization of untrusted data means the application turns serialized, attacker-controlled input back into live objects or code structures, without sufficient validation. Here the consequence is the gravest possible: an unauthenticated attacker can execute code inside the identity service itself.

The flaw was discovered by Robert Fitzpatrick, a Microsoft principal security engineer. The vector is remote, account-free, and interaction-free — the triplet that justifies the 10.0.

A contradictory timeline

The public record is murkier than the advisory suggests. Help Net Security first reported the flaw as “exploited in the wild”, before Microsoft corrected an “Exploited” flag attached to the CVE. The result: the vulnerability is not in CISA’s KEV, the reference list of actively exploited flaws.

That back-and-forth matters. A withdrawn “exploited” flag, an absence from the KEV, and a patch “already applied” server-side leave a CISO with no independent way to know whether exploitation actually happened, or for how long.

Microsoft has not disclosed who was behind any exploitation, when it began, how many organizations were affected, or what attackers did once inside the service. The “further transparency” stops at the statement itself.

The opacity of the cloud patch

This is the core point. A server-side patch on a multi-tenant service you do not deploy is, by nature, invisible: no binary to download, no version to check, no reboot to schedule. You cannot confirm the fix is in place other than by trusting the vendor.

That opacity inverts the balance of traditional security. On an on-premise product, you control the patch; on a cloud service, you control only your signals — sign-in logs, audits, permission changes. Your defense perimeter shifts from patching to detection.

It is also a lesson in shared responsibility. Microsoft patches the service; you patch what the service cannot patch for you: accounts, roles, conditional access, and monitoring.