Microsoft Entra ID Insecure Deserialization (CVE-2026-69836)

CVE-2026-69836 is a CVSS 10.0 deserialization flaw in Microsoft Entra ID, and it was not exploited in the wild. Both halves of that sentence are load-bearing, because one of the two KEV catalogs this publication ingests says otherwise — and it is wrong.

Microsoft’s advisory states the exploitation status plainly: Exploited: No, Publicly disclosed: No, exploitability assessment “Exploitation Less Likely.” The vector carries E:U, the temporal metric denoting unproven maturity, which is consistent with the same conclusion. VulnCheck’s KEV feed nonetheless carries this CVE as exploited, dated August 20, 2026. CISA never listed it at all.

Why the discrepancy exists

Microsoft’s own revision history resolves it. The advisory was first published on August 20, 2026, and revised the following day:

Version 1.1, August 21, 2026 — “Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only.”

So Microsoft’s initial publication carried the exploitation flag set incorrectly and retracted it within twenty-four hours. VulnCheck’s catalog entry is dated August 20 — the same day as that first, erroneous version. The most economical explanation, and the one the dates support, is that VulnCheck captured the original flag and has not reflected Microsoft’s next-day correction. CISA’s absence from the picture is then not an oversight but the expected outcome: there was never real-world exploitation for CISA’s criteria to admit.

This is an assessment of how the data came to disagree, not a claim about VulnCheck’s internal process, which we cannot observe. What is directly verifiable is the sequence: Microsoft flagged, Microsoft corrected, one downstream catalog still reflects the pre-correction state twenty-eight days later.

What the vulnerability actually is

Microsoft is the assigning CNA and classifies the flaw as CWE-502 (Deserialization of Untrusted Data), with an impact of remote code execution and a maximum severity of Critical. Per the advisory’s executive summary, untrusted deserialization in Entra ID allowed an unauthorized attacker to execute code over a network. NVD’s record carries the same classification and the same description.

The severity figures are genuinely well-corroborated, which is worth separating from the exploitation question:

Microsoft additionally publishes a temporal score of 8.7 alongside the 10.0 base, reflecting E:U (unproven maturity), RL:O (official fix available), and RC:C (confirmed report). The temporal metrics are the part of CVSS designed to carry exactly this kind of real-world context, and they point the same way the advisory’s exploitation table does.

The score reaches 10.0 rather than 9.8 because scope is assessed as changed (S:C) — impact crossing out of the vulnerable component into resources under a different security authority. For an identity provider that assessment needs little defending: Entra ID is the control plane other systems delegate authentication to.

There is nothing for a customer to patch

This is a cloud-service CVE, and the advisory is explicit that no customer action applies. Microsoft states the vulnerability “has already been fully mitigated by Microsoft,” that there is no action for users of the service to take, and that the CVE exists to provide transparency under its policy of issuing identifiers for cloud-service vulnerabilities it has already fixed.

That reframes what this record is for. A CVSS 10.0 on a customer-managed product is a patch instruction. A CVSS 10.0 on a vendor-operated service that was remediated before disclosure is a disclosure artifact — useful for understanding the provider’s security posture and for audit trails, but not something that belongs in a patch queue. Reading it as the former produces wasted triage cycles chasing an update that does not exist.

Why this matters

The practical lesson is about catalog hygiene rather than Entra ID. A KEV listing is normally the strongest single signal in vulnerability triage, which is precisely why a stale one is costly: it survives exactly because people trust it enough not to re-check. Anyone whose prioritisation pipeline treats “present in a KEV feed” as a terminal fact would have escalated a CVSS 10.0 identity-provider CVE that was never exploited and cannot be patched — and would have found nothing to do at the end of it.

Two habits follow, and both are cheap. First, distinguish the catalogs: CISA KEV and VulnCheck KEV are not interchangeable, and where they disagree the disagreement is itself the signal worth investigating. Second, for a vendor-assigned CVE, read the vendor advisory’s revision history and not only its current state — a retraction lives there and nowhere else. Neither NVD’s record nor VulnCheck’s entry for this CVE reflects Microsoft’s August 21 correction.

This publication’s own coverage is affected by the same distinction. The three maximum-severity advisories we published from VulnCheck-only listings — CVE-2026-82222 in GiveWP, CVE-2026-82970 in WP Cookie Notice, and CVE-2026-73343 in WP Compress — each state their exploitation report as single-sourced and uncorroborated rather than settled, which is the posture this case vindicates. Those three trace to third-party advisories rather than a vendor CNA with a published revision history, so the specific retraction mechanism seen here does not apply to them; the general caution does.

For the same CWE-502 weakness class where exploitation is genuinely CISA-confirmed, see CVE-2026-86404 in Red Hat AMQ Artemis. For other Microsoft CVEs in recent CISA KEV tranches, see CVE-2026-85880 and CVE-2026-81963, both of which carry real CISA listings and real remediation obligations — the contrast with this record is the point.

Evidence and confidence

• High confidence — the CVSS 10.0 base score, the base vector, and the CWE-502 classification, each independently carried by both NVD and Microsoft. Also the non-exploitation finding: Microsoft is both the assigning CNA and the service operator, making it authoritative for whether its own cloud service was attacked, and its explicit v1.1 correction removes any basis for doubt.
• High confidence — that VulnCheck’s KEV feed carries this CVE as exploited with an August 20, 2026 date. That is directly observed in our own ingested provenance data, and reporting the discrepancy accurately requires stating it.
• Resolved conflict — the exploitation field is the one place our sources disagree. We are not splitting the difference or presenting both as equally weighted: the vendor’s corrected advisory governs, and the contradicting value is explained by its timing rather than left open.
• Unknown — exploitation probability. No EPSS score has been ingested for this CVE, though the question is largely moot for an already-remediated service.

CVE-2026-69836 is not listed in CISA’s Known Exploited Vulnerabilities catalog as reflected in our ingestion through September 16, 2026. Our D1 also carried no MSRC per-field provenance rows for this CVE — the MSRC data reached us as a release-level record and a reduced raw payload that omits the exploitation field entirely, which is why the advisory itself had to be consulted directly.

Frequently Asked Questions

Was CVE-2026-69836 exploited in the wild? No. Microsoft’s advisory states Exploited: No and its August 21, 2026 revision explicitly corrected an earlier entry, recording that the vulnerability was not exploited in the wild.

Why does a KEV feed list it as exploited then? VulnCheck’s KEV entry is dated August 20, 2026, the same day Microsoft first published the advisory with the exploitation flag set incorrectly. Microsoft corrected it on August 21; that correction is not reflected in the VulnCheck entry as of our September 16, 2026 ingestion.

What is CVE-2026-69836? A CVSS 10.0 deserialization-of-untrusted-data vulnerability (CWE-502) in Microsoft Entra ID that, per Microsoft, allowed an unauthorized attacker to execute code over a network.

What do I need to patch? Nothing. Microsoft states the vulnerability was already fully mitigated service-side and that there is no action for users of the service to take. The CVE was issued for transparency under Microsoft’s cloud-service disclosure policy.

Does this CVE create a federal patching deadline? No. Binding Operational Directive 26-04 obligations follow CISA KEV listing, and this CVE is not CISA-listed — correctly so, since it was not exploited.

Is a CVSS 10.0 score still meaningful if it was never exploited? Yes, but it measures something different from what triage often assumes. The base score describes potential technical impact if exploited; it says nothing about whether exploitation occurred. Microsoft’s temporal score of 8.7, which incorporates unproven maturity and an available official fix, is the figure that reflects real-world conditions.

Severity, vector, and weakness classification corroborated by the National Vulnerability Database record for CVE-2026-69836 and Microsoft’s own advisory. Exploitation status, temporal metrics, revision history, and remediation guidance sourced from the MSRC Security Update Guide entry for CVE-2026-69836, consulted September 17, 2026. The contradicting exploitation claim is carried by VulnCheck KEV, an authenticated feed with no public per-CVE page to cite. Not listed in CISA’s Known Exploited Vulnerabilities catalog as reflected in our ingestion through September 16, 2026. See more vulnerability intelligence.