Microsoft Called Its Own Entra ID Bug "Exploited." Then It Didn't.
CVE-2026-69836 is a perfect-10 deserialization RCE in a cloud service nobody can patch themselves. For a few days, the only signal customers had — Microsoft's own "Exploited" flag — flipped from Yes to No with no real explanation.
Pavel Buchnev6 min read
On August 20, 2026, Microsoft published an advisory for CVE-2026-69836, a deserialization bug in Entra ID — its cloud identity service — carrying the maximum possible CVSS score: 10.0. The advisory's exploitability field said the flaw had already been used in attacks. Within days, that field changed to "No," and Microsoft has not given a technical explanation for why. There is no patch for customers to apply — Entra ID is cloud-hosted and Microsoft fixed it server-side — which means the "Exploited" flag wasn't a footnote to this story. For a few days, it was the only signal enterprise security teams had.
Scores as of 2026-08-24live record →
What the advisory actually says
Microsoft's own description is terse: "Deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network." No privileges, no user interaction, network attack vector, low complexity — that combination is why the CVSS engine landed on 10.0. Microsoft credited Principal Security Engineer Robert Fitzpatrick with discovering the issue, and its own line to press was blunt about scope: "We identified and addressed this issue with a fix and released CVE-2026-69836 for greater transparency."
| Field | Value |
|---|---|
| Advisory published | August 20, 2026 |
| CVSS 3.1 | 10.0 Critical (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) |
| Weakness | CWE-502 — Deserialization of Untrusted Data |
| EPSS | 1.6% (73.7th percentile) as of today |
| Affected product | Microsoft Entra ID (cloud service — no version to patch) |
| Fix | Applied server-side by Microsoft; no customer action required |
| Discovered by | Microsoft Principal Security Engineer Robert Fitzpatrick |
| Public exploit code | None known |
The flip: Yes, then No
This is the part that made the story travel. Multiple outlets that covered the advisory on or shortly after publication — including BleepingComputer and SecurityWeek — reported the exploitability field as "Yes." The Hacker News says Microsoft corrected that field to "No" after it queried the company directly, and quotes a Microsoft spokesperson confirming: "this vulnerability was not exploited in the wild." Help Net Security's own article carries an editor's note dated August 24 — today — recording the same reversal and stating Microsoft "confirmed to Help Net Security that the vulnerability was not exploited in the wild."
How the exploitability field moved
- Advisory published, CVSS 10.0Microsoft's Entra ID advisory for CVE-2026-69836 goes live. Early coverage (BleepingComputer, SecurityWeek) reports the "Exploited" field as Yes.
- The Hacker News reports a correctionAfter querying Microsoft directly, The Hacker News reports the field changed to No and publishes a Microsoft spokesperson quote confirming no in-the-wild exploitation.
- Other outlets update in step — todayHelp Net Security and SecurityWeek run editor's-note updates on the same date recording the No status and Microsoft's confirmation to them separately.
Why the flag matters more than usual here
For an on-prem CVE, "Exploited: Yes/No" is one input among many — you also have your own telemetry, your patch status, your EDR alerts. For a cloud-only service like Entra ID, none of that applies. There's no version number to check, no patch to schedule, no log on your own infrastructure that would show whether the vulnerable code path in Microsoft's backend was ever hit against your tenant. Microsoft's own exploitability assessment is the risk signal — full stop. When that signal is wrong for even a few days, defenders lose the one lever they had to decide whether this needed an incident-response posture (checking sign-in logs, reviewing service-principal changes, briefing leadership) or just a note-and-move-on.
What's confirmed vs. what's still unknown
- CVSS 10.0, CWE-502 deserialization, unauthenticated, network-reachable
- Discovered internally by Robert Fitzpatrick, not via a third-party report
- Fully mitigated server-side; no customer action required
- Exploitability status corrected from Yes to No after press inquiries
- "Not exploited in the wild," per spokesperson statements to two outlets
- Why the field was set to Yes in the first place, then reversed
- Any technical explanation for the correction beyond "informational only"
- Who, if anyone, attempted exploitation, and when
- Attack chain or technical details of the deserialization flow
- Whether any customer tenant showed suspicious activity tied to this path
The EPSS number nobody's talking about
What Entra ID admins can actually do
There's no patch to deploy, so "do something" here means tightening the controls that would catch abuse of this class of flaw if it ever recurs, and preserving the evidence you'd need if Microsoft discloses more later:
- Retain Entra ID sign-in, audit, and application logs for the retrospective window — Microsoft hasn't given a start date for any attack activity, so you can't yet target a specific period to review
- Review service-principal and application permission changes for anything unexplained, since deserialization RCE in an identity service is exactly the kind of bug that would be used to mint or modify app credentials
- Confirm conditional access policies and MFA enforcement are actually applied tenant-wide, not just to a subset of users, since a compromised identity backend bypasses front-door controls that assume the backend is trustworthy
- Make sure your team is actually subscribed to Microsoft Security Response Center notifications — this is the kind of correction that's easy to miss if you only read the headline the first time it ran
Status current as of 2026-08-24live record →