CVE-2026-69836 Entra ID Vulnerability: The CVSS 10.0 RCE With Nothing to Patch and Everything to Hunt

CVE-2026-69836 Entra ID Vulnerability: What Happened and Why It Matters

On August 20, 2026, Microsoft published an advisory for CVE-2026-69836, a vulnerability in Microsoft Entra ID that scored a perfect CVSS 10.0. The official title is blunt: "Microsoft Entra ID Remote Code Execution Vulnerability." Per Microsoft's own advisory, the root cause is deserialization of untrusted data, and the impact is remote code execution by an unauthenticated attacker over the network — no credentials, no user interaction, no prerequisite access.

For a tenant's identity provider, that combination is about as bad as a rating gets. Entra ID is the control plane that issues every token, evaluates every Conditional Access policy, and gates every privileged role activation in a Microsoft 365 or Azure environment. A remote code execution flaw in that control plane, reachable without authentication, is a five-alarm finding on paper.

But this is also a cloud-service CVE, and that changes the playbook. There is no downloadable patch, no KB article, and no maintenance window. Microsoft fixed the vulnerable code server-side before most defenders had even seen the advisory. That single fact — nothing to install — is exactly what makes this CVE worth reading closely rather than skimming past.

Inside the Flaw: CWE-502 Deserialization and a Perfect CVSS Score

Microsoft classifies CVE-2026-69836 under CWE-502, Deserialization of Untrusted Data. In plain terms: somewhere in the Entra ID service, incoming data was being converted back into live objects without sufficiently validating where that data came from or what it contained. Deserialization bugs are a well-known class of remote-code-execution primitive — attackers craft a malicious serialized payload that, once reconstructed by the vulnerable code, executes arbitrary logic instead of just rehydrating a data structure. It's the same bug family behind some of the most damaging Java and .NET RCEs of the last decade, and it now has an Entra ID entry.

The CVSS 3.1 base vector Microsoft published is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Read left to right, every metric maxes out the severity: AV:N (attack vector: network — reachable over the internet), AC:L (attack complexity: low — no special conditions needed), PR:N (privileges required: none — unauthenticated), UI:N (user interaction: none), S:C (scope: changed — the flaw affects resources beyond the vulnerable component), and C:H/I:H/A:H (high impact to confidentiality, integrity, and availability). That combination is what produces the base score of 10.0. Microsoft's temporal score sits at 8.7, reflecting the three temporal metrics it appends to that same vector string — E:U (exploit code maturity: unproven), RL:O (remediation level: official fix), and RC:C (report confidence: confirmed) — layered on top of the unauthenticated network RCE.

The Exploitation Flip-Flop: What Microsoft Corrected — and Why That Matters More Than the Score

Here is the detail that makes this CVE genuinely instructive rather than just another critical-severity headline: Microsoft's own advisory revision history shows the exploitation status changed the very next day.

• Revision 1.0 — August 20, 2026: "Information published."
• Revision 1.1 — August 21, 2026: "Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only."

Several outlets that covered the disclosure on August 21 — including Help Net Security, The Hacker News, and The Register — reported the CVE at a moment when its exploitation status was still in flux, before Microsoft locked it in as "Exploited: No." The Register in particular noted that Microsoft characterized the correction as "informational only," and that no technical detail of an actual attack chain has been published anywhere.

Microsoft's current, corrected position, straight from the advisory's Exploit Status field, reads:

Publicly Disclosed: No
Exploited: No
Latest Software Release: Exploitation Less Likely

Why There's No Patch to Apply — and Why That's Not the Same as "Nothing to Do"

Microsoft's FAQ for CVE-2026-69836 is explicit about the remediation model: "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 advisory links to Microsoft's own explainer on why cloud-service CVEs work this way, "Toward greater transparency: Unveiling Cloud Service CVEs" (aka.ms/MSRC-Cloud-CVEs).

That's a legitimate and increasingly common model for SaaS control planes: Microsoft owns the code, Microsoft owns the fix, and the CVE exists purely so the industry has a public record that a critical flaw existed and was closed. The researcher credited for the find, Robert Fitzpatrick, is listed in Microsoft's own advisory as reporting with Microsoft — this was caught and closed internally, not by an external red team publishing a working exploit.

None of that erases the fact that, for some window of time, an unauthenticated, network-reachable RCE primitive existed in your identity provider. "Fully mitigated" describes the vulnerability going forward. It says nothing about what may or may not have happened during the window it was open — and while Microsoft states flatly that the flaw "was not exploited in the wild," it publishes neither the evidence nor the scope behind that conclusion.

Detection: Hunting When There's No Attack Chain Published

This is the uncomfortable part: Microsoft has not published IOCs, a CVE-specific detection rule, or any description of what an exploitation attempt against this flaw would look like. There is nothing to signature-match against. That doesn't mean hunting is pointless — it means the hunt has to be built from what a successful Entra ID RCE would plausibly touch, not from a vendor-supplied playbook.

Why Log Retention Comes First

Before any of this is possible, your tenant needs logs that actually cover the window. If your Entra ID audit log retention is short, this entire exercise is moot for anything more than a few days back.

Pulling the Raw Data

# Pull sign-in logs covering the disclosure/correction window (UTC timestamps).
# Requires the AuditLog.Read.All permission. The spaces inside $filter must be
# percent-encoded: curl rejects a URL that contains raw spaces before it sends anything.
curl -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=createdDateTime%20ge%202026-08-19T00:00:00Z%20and%20createdDateTime%20le%202026-08-22T00:00:00Z"

Feed the output into whatever anomaly review process you already run for sign-in data — the point isn't a magic query, it's making sure the window is actually queryable at all.

Remediation: A Compensating-Control Checklist, Not a Patch

There is no vendor patch to deploy for CVE-2026-69836. What you can do is make sure the controls that would catch the consequences of an identity-provider compromise — this one or the next one — are actually turned on.

Identity Protection and Conditional Access

1. Enable a sign-in risk policy in Identity Protection. Without one, Entra ID computes risk signals but nothing acts on them.
2. Back it with a risk-based Conditional Access policy that steps up authentication or blocks access when sign-in risk is elevated, rather than relying on the risk score alone. See our breakdown of common Conditional Access baseline coverage gaps for what a complete policy set looks like.
3. Turn on automated risk response so risky sessions are acted on in near real time instead of waiting for a manual review cycle — read more in our guide to Entra ID Identity Protection risk policies.

Logging and Ongoing Review

4. Extend audit log retention to a window that actually supports retrospective hunting, not just day-to-day troubleshooting. Our piece on Entra ID logging, retention, and diagnostic settings covers the practical configuration.
5. Review high-privilege service principals and their sign-in activity for anything unexpected around the disclosure window — our article on service principal sign-in anomaly detection walks through what a workload-identity baseline looks like.
6. Subscribe to MSRC advisory update notifications. This CVE's exploitation status changed a day after publication — if you only read the disclosure-day headline, you missed the correction.

This is not the first Entra ID CVE this year to ship with "no customer action required." We covered the same zero-patch pattern in CVE-2026-62869, an Entra ID spoofing vulnerability, and again in CVE-2026-50481, an Azure Active Directory elevation-of-privilege flaw — a CVSS 9.9 that also shipped with an empty remediation list and Customer Action Required: No. The pattern is becoming routine: Microsoft ships the fix, and the only thing left for tenants to do is decide how hard to look backward.

How EtcSec Detects This

EtcSec's Azure audit does not — and cannot — detect exploitation of a service-side CVE like CVE-2026-69836; that visibility sits entirely inside Microsoft's own infrastructure. What it does check for are exactly the gaps that turn an incident like this one into a blind spot: whether a sign-in risk policy exists at all, whether that risk is backed by a risk-based Conditional Access policy, whether risk responses are automated instead of manual, whether audit log retention is long enough to support a retrospective hunt, and whether service principals hold administrative privilege without ongoing review.