A CVSS 10.0 RCE in Entra ID was exploited in the wild, and there was nothing to patch

Microsoft has fixed a remote code execution flaw in Entra ID, tracked as CVE-2026-69836 and carrying the maximum CVSS score of 10.0, which Help Net Security reports was exploited in the wild ^[1][2]. The flaw sat in the service that verifies logins and controls access to Microsoft 365, Azure and connected third-party apps, which means the compromised component was the one customers do not run, cannot patch and cannot take offline ^[6].

The technical shape is old and familiar. Microsoft's advisory states that "deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network" ^[4]. No authentication was required, and the execution happened inside Microsoft's cloud identity service rather than on anything a tenant administrator owns ^[3]. The finder is credited as Robert Fitzpatrick, a Microsoft Principal Security Engineer, so this was found in-house ^[5].

Then the part that matters operationally. "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," the company said ^[7]. Read that alongside the exploitation claim and the sequence becomes clear: defenders were told about an exploited maximum-severity identity flaw only after the fix was already complete, so there was never a patch window to manage or miss ^[9]. There is no configuration change, no version to inventory, no compensating control to stand up ^[10].

That leaves customers with two things, and neither is under their control. The first is log review, because if code ran unauthenticated inside the identity service, the only tenant-side evidence of consequence would be in sign-in and audit trails and in the downstream systems Entra ID grants access to ^[6][3]. The second is Microsoft's disclosure practice, which is currently the sole source of scope. Microsoft has not disclosed who was behind the exploitation, when it started, how many organizations were affected, or what the attackers did once inside the vulnerable service ^[8].

A transparency CVE is better than silence, and Microsoft deserves to be told so plainly. But a CVE without a timeline is not something a security team can act on. Without a start date, no one can bound a log search. Without an affected-tenant count or any indicator of compromise, no one can rule themselves out, and "no action required" is doing double duty as both a reassurance and a full stop ^[7][8]. For a flaw scored at 10.0 in the system that issues the tokens everything else trusts, that gap is the story ^[2][6].

The uncomfortable structural point: shared-fate cloud identity means the vendor's incident response is your incident response, and the vendor's disclosure detail sets the ceiling on what your own investigation can even ask. This CVE proves the identity control plane is a live, exploited attack surface, not a theoretical one ^[1]. Everything after that proof depends on what Microsoft chooses to publish.

What to watch: whether Microsoft follows up with an exploitation timeline, indicators or an affected-tenant estimate, since a start date is the minimum needed to scope a retrospective log hunt ^[8]. Watch also whether the "CVE issued purely for transparency" pattern becomes routine for Microsoft-operated services, and whether it comes with the detail defenders would need, or stays at the level of this advisory ^[7].