Entra ID RCE at CVSS 10.0 Was Exploited Before Anyone Outside Microsoft Knew It Existed

Microsoft confirmed that attackers exploited a maximum severity flaw in Entra ID, the identity service that fronts authentication for Microsoft 365, Azure, and thousands of federated SaaS applications. CVE-2026-69836 carries a CVSS base score of 10.0 and permits an unauthorized attacker to execute code over a network. Microsoft says the flaw is fully mitigated on its side and that no customer action is required. That last part is the whole advisory for most defenders, and it is also the problem: there is nothing to patch, nothing to verify, and not one published indicator to hunt on.

What Microsoft actually disclosed

The alert went out Thursday, August 20, 2026. Microsoft describes the root cause as deserialization of untrusted data in Entra ID, the service formerly known as Azure Active Directory. Deserialization bugs occur when an application converts attacker controlled input back into a live object without validating it first, which can yield code execution, denial of service, or access control bypass. Microsoft credited its own Principal Security Engineer, Robert Fitzaptrick, with finding and reporting the issue.

That is the complete set of published facts. Everything a responder would need is missing:

• No exploitation window. Microsoft has not said when the attacks began, how long they ran, or whether they are ongoing.
• No attribution. No actor, no cluster name, no tradecraft.
• No indicators. No IPs, no user agents, no audit log event signatures.
• No blast radius. Microsoft has not stated whether exploitation touched one tenant, a region, or the service globally, and has not said whether affected tenants were notified individually.
• No detail on discovery. It is unclear whether the exploitation was found through internal telemetry, incident response, or the same research that produced the report.

Why a 10.0 here is not a 10.0 in your data center

A CVSS 10.0 means network attack vector, no privileges required, no user interaction, and a scope change beyond the vulnerable component. On a server you own, that is bad. On the identity plane that issues your tokens, it sits upstream of every control you built on top of it. Conditional access, MFA enforcement, sign-in risk policies, and app consent restrictions all assume the issuer is trustworthy. Code execution inside the issuer makes those assumptions negotiable.

There is also no endpoint telemetry to fall back on. Nothing about this ran on your hosts, so EDR saw nothing, your network sensors saw nothing, and your vulnerability scanner has no asset to flag. The only evidence that would ever reach you is second order: what an attacker did with the access inside your tenant.

Hunt the aftermath, not the exploit

You cannot detect exploitation of CVE-2026-69836. You can look for the durable artifacts that any competent operator would leave behind after gaining that level of access. Prioritize these in your Entra ID audit logs, going back as far as retention allows:

• Add service principal credentials and Update application, Certificates and secrets: the single most common identity persistence technique, and it produces a credential that no password reset touches.
• Set federation settings on domain and Add unverified domain: federation takeover lets an attacker mint tokens for arbitrary users in the tenant.
• Add member to role and Add eligible member to role, focused on Global Administrator, Privileged Role Administrator, Application Administrator, and Cloud Application Administrator.
• Consent to application, especially tenant wide admin consent granting Graph permissions such as Directory.ReadWrite.All, Mail.Read, or Application.ReadWrite.All.
• Sign-in logs and MSGraphActivityLogs for service principal authentications from ASNs and geographies your workloads never use.
• Cross Tenant Access Settings and Partner Relationships changes, which quietly widen who can reach your directory.

Retention is the constraint that will bite you. Entra ID keeps audit and sign-in logs for 7 days on the free tier and 30 days with a P1 or P2 license. If the exploitation window predates that, the evidence is already gone unless you export diagnostic settings to Log Analytics, a storage account, or a SIEM. Since Microsoft declined to state the window, you have no way to know whether your retention covers it. If you are not exporting Entra ID logs today, that is the durable fix this incident should buy you.

The second exploited Microsoft flaw this month

Earlier in August, Microsoft patched CVE-2026-68820, a privilege escalation flaw in the Windows Ancillary Function Driver for WinSock scoring 7.0, exploited as a zero day by the North Korea linked Lazarus Group under the long running Operation Dream Job campaign. The contrast matters for how you brief leadership. The WinSock bug is a lower score with a higher operational burden, because you own the patching. The Entra ID bug is a perfect score with zero patching burden and zero visibility. Severity and workload are not the same axis, and your exposure reporting should stop treating them as one.

What to do this week

• Turn on Entra ID diagnostic settings and ship audit, sign-in, and MSGraphActivityLogs to long term storage if you have not already. Ninety days minimum, one year preferred.
• Inventory every service principal and app registration credential, flag anything added in the last 90 days, and remove what nobody can account for.
• Review federated domains and cross tenant access settings against a known good baseline.
• Enumerate tenant wide admin consents and revoke Graph permissions no active workload needs.
• Build standing detections for the audit events listed above so the next identity plane incident produces an alert instead of a retroactive log hunt.

The uncomfortable takeaway is not that Microsoft shipped a deserialization bug. It is that the shared identity plane is now a place where a confirmed, exploited, maximum severity remote code execution flaw can come and go without customers ever learning when they were exposed. Assume you will get that advisory again. Build the log retention and the baselines now so that next time you can answer the question yourself.