Tech Infrastructure

Tech Infrastructure Risk: Entra ID CVSS 10.0 RCE Flaw

Published August 22, 2026 · DNS Benchmark Pro Editorial · Reading time: 5 minutes

TL;DR — The most significant piece of tech infrastructure news this week involves a system almost nobody administers directly. On 20 August 2026 Microsoft disclosed CVE-2026-69836, a CVSS 10.0 remote code execution flaw in Entra ID — the cloud identity service formerly known as Azure Active Directory. The root cause is deserialization of untrusted data (CWE-502), exploitable over a network with no authentication and no user interaction. Microsoft says the issue was fully mitigated on its own side, with no customer action required. The advisory initially marked the flaw as exploited in the wild; on 21 August, after press enquiries, Microsoft corrected that field to "No" and stated the vulnerability was not exploited. Both versions of that story matter.

Most tech infrastructure incidents give administrators something to do. This one does not, and that is precisely what makes it worth reading about. CVE-2026-69836 landed in a service that authenticates logins and brokers access to Microsoft 365, Azure and thousands of federated third-party applications. There is no patch to stage, no maintenance window to negotiate, no version table to audit. Microsoft fixed the vulnerable component in its own estate and told customers there is nothing to install — which leaves IT security teams with a harder question than "when do we reboot?"

What CVE-2026-69836 actually is

Microsoft's advisory language is terse: "Deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network." That single sentence is close to the entirety of the public technical record.

Deserialization flaws occur when software reconstructs an object graph from attacker-controlled bytes without validating what it is rebuilding. Because the serialized payload can describe types, constructors and property setters, a permissive deserializer can be coaxed into instantiating classes whose side effects the developer never intended — the classic gadget-chain path to code execution. The same class of bug also produces denial-of-service and access-control bypass outcomes, which is why OWASP and MITRE treat CWE-502 as a high-impact primitive rather than a parsing nuisance.

Microsoft credited principal security engineer Robert Fitzpatrick with finding and reporting the issue. It has not named the affected backend component, the reachable endpoint, the payload structure, or what privileges successful exploitation would have conferred inside the service.

Why a deserialization bug earns a perfect 10

CVSS metric	Value	Consequence
Attack vector	Network	Reachable from the internet, not a tenant-local adjacency
Attack complexity / privileges	Low / None	No account, no token, no prior foothold
User interaction	None	No phishing step, no click, no consent prompt
C / I / A impact	High / High / High	Full compromise of the affected component

Perfect scores are rare because they require every metric to be maximal simultaneously. When one lands in the identity plane rather than in an edge appliance, the theoretical blast radius is not a device — it is the authentication decisions that every downstream service trusts without re-checking.

Verified DNS Benchmark Pro capture showing DNS server performance and network latency measurements used to separate identity-service failures from resolver failures during a tech infrastructure incident — Verified, unmodified capture from the DNS Benchmark Pro engine. When a cloud identity service misbehaves, the user-visible symptom is usually "Microsoft 365 is down" — which is indistinguishable at the helpdesk from a resolver problem. Measuring resolver reachability first removes one whole branch of the fault tree before an incident bridge starts guessing.

The exploited flag that changed direction

When the bulletin appeared on Thursday, the Exploitability Assessment table carried Exploited: Yes. Every major outlet — this one included, had we published on Thursday — reported a maximum-severity cloud identity flaw under active attack. On Friday 21 August, after The Hacker News contacted Microsoft for comment, the company corrected the field to No and stated that the vulnerability was not exploited in the wild. A spokesperson said the issue was identified and fixed internally, and the CVE was published "for greater transparency," under the cloud-service CVE programme Microsoft introduced in 2024.

It is worth being precise about what that correction does and does not resolve. It removes the claim of observed attacker activity. It does not change the CVSS metrics, the class of bug, or the fact that a deserialization endpoint existed in the identity plane of a hyperscale platform. And it introduces a second-order problem for anyone running a vulnerability-intelligence pipeline: an authoritative source emitted a machine-readable exploitation signal, hundreds of downstream feeds ingested it, and the retraction will not propagate everywhere the original did. Teams that auto-escalate on the MSRC exploited flag should check whether their tooling re-reads advisories after first ingestion, because plenty do not.

Cloud CVEs and the visibility gap in enterprise IT security

Microsoft began issuing CVEs for vulnerabilities in its own cloud services in 2024 specifically for cases where customers have nothing to patch. That is a genuine improvement over silent server-side fixes — but it produces advisories that are transparency artefacts rather than work items, and the industry has not settled on how to triage them.

For a self-hosted product, an advisory answers three questions: am I affected, what do I install, and how do I tell whether I was hit. A cloud CVE answers only the first, and answers it with "yes, and it is already over." The third question — was my tenant touched — remains open, and it is not one Microsoft's advisory format is designed to close. Customers cannot audit the vulnerable code path, cannot search their own logs for a payload signature nobody published, and cannot independently establish a timeline. This is the structural trade of running identity as a managed service: you inherit the vendor's patch velocity, which is excellent, and the vendor's disclosure granularity, which is not.

What defenders can reasonably do

Re-fetch the advisory before acting on it. MSRC entries are mutable. A flag that read "exploited" on Thursday may not on Friday, and vice versa.
Review sign-in and audit logs anyway. Entra ID sign-in logs, audit logs and provisioning logs are yours. Unexplained service principal grants, new credentials on existing app registrations, and unfamiliar consent events are worth a look regardless of this CVE.
Reduce standing privilege. Nothing in this incident is mitigated by least privilege, but everything that follows an identity compromise is. Privileged Identity Management, short token lifetimes and conditional access remain the controls that bound the damage.
Do not treat the absence of a KEV listing as reassurance. As of publication CVE-2026-69836 does not appear in CISA's Known Exploited Vulnerabilities catalog, which is consistent with the corrected status — and also with the catalog's remit, which is remediable software.

The DNS security parallel most teams miss

There is a useful analogy here for anyone who has run resolvers. DNS spent two decades being treated as plumbing until the industry worked out that whoever answers your queries effectively decides where your traffic goes. Cloud identity is now in the same position: whoever can influence the token issuer decides who your systems believe you are. Both are shared, invisible, high-trust server infrastructure, and both fail in ways that look like something else — a "slow app," a "login loop," a "site is down."

That is not a rhetorical flourish; it changes triage. During any suspected identity-plane event, the first job is to separate authentication failure from name resolution failure, because the two present identically to end users. A thirty-second check of DNS server performance and network latency from the affected client — using a browser-based network diagnostic tool that requires no agent install — either eliminates the resolver path or finds a stale DNS over HTTPS configuration that a VPN or endpoint agent left behind. Both outcomes are useful. Neither takes longer than reading the advisory.

Chart from an earlier release of the DNS Benchmark Pro tool comparing DNS-over-HTTPS response times and network latency across public resolvers in a tech infrastructure review — Unmodified capture from the DNS Benchmark Pro engine as it stood in August 2026. **Correction (15 August 2026):** the release that produced this chart timed opaque browser requests and did not verify that a response was a valid DNS answer, so the figures shown may include HTTP errors and unreadable replies counted as fast responses. They should not be relied on. The engine was rebuilt to validate every response; see the current methodology. The point the chart illustrates — that comparing the whole field beats spot-checking one provider — still holds.

What this means for the industry

Two things are true at once. Microsoft found and fixed a maximum-severity flaw in its own identity service before anyone demonstrably abused it, then disclosed it when it had no commercial reason to — that is the transparency programme working as designed. And the same week produced a reminder that cloud CVEs travel through an ecosystem built for on-premises software, where advisories are assumed to be immutable and exploitation flags are assumed to be durable.

For enterprise IT and cloud security teams, the practical lesson is not about Entra ID specifically. It is that the modern tech infrastructure stack now contains critical components you cannot patch, cannot instrument, and cannot forensically examine — and your incident process needs a defined path for them. That path is mostly logging discipline, privilege reduction, and the humility to re-read a source before escalating on it. The parts of your tech infrastructure you can measure directly deserve more attention precisely because so much of the rest has moved out of reach.

Verifying a client after an identity or connectivity incident? Run the free browser-based DNS speed test, read how the benchmark measures DNS over HTTPS latency and jitter, or revisit our report on the Cisco ASA and FTD VPN denial-of-service flaw for the on-premises version of the same edge-of-trust problem.

Sources

Published by Genext Information Systems · August 22, 2026. DNS Benchmark Pro is an independent tool and is not affiliated with Microsoft, CISA or any vendor named in this article. This report summarises publicly available vendor disclosures and press reporting and is provided for informational purposes; MSRC advisories are subject to revision, so verify the current status of CVE-2026-69836 against the linked Microsoft advisory before acting. Both images on this page are genuine, unmodified screen captures from the DNS Benchmark Pro engine. No AI-generated imagery is used on this page.