On 20 August, Microsoft published an advisory for a maximum-severity remote code execution flaw in Entra ID and marked it as exploited in the wild. On 21 August, Microsoft filed revision 1.1 with a one-line correction: “Corrected Exploited to No. This vulnerability was not exploited in the wild.” A number of the articles written during that twenty-four hour window are still up, still uncorrected, and still telling readers that a perfect-10 flaw in the identity service they depend on came under attack.
There is nothing for you to patch here. That is the point of running it.
What happened
CVE-2026-69836, titled by Microsoft “Microsoft Entra ID Remote Code Execution Vulnerability.” The description: “Deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network.” CWE-502.
Base score 10.0 critical, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The scope change — S:C — is what carries it from 9.8 to a perfect 10.
What is affected is Entra ID itself, the cloud service. The CVE record lists the product with version “-” and carries Microsoft’s CNA tag exclusively-hosted-service. This is not Entra Connect, not a sync agent, not a connector, not anything installed on a server you own. There is no version range because there is nothing you run.
Consequently, customer action required: no. Microsoft’s advisory FAQ, verbatim: “This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take.” The CVE was published under Microsoft’s cloud transparency initiative — an advisory that exists to tell you something happened, not to give you something to install.
The correction
The MSRC revision history is short and worth reading in full:
- Revision 1.0, 20 August 2026: “Information published.”
- Revision 1.1, 21 August 2026: “Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only.”
The advisory currently records Exploited: No, Publicly Disclosed: No, and an exploitability assessment of “Exploitation Less Likely.” CISA’s own enrichment record sets exploitation status to none. It is not in KEV.
So for roughly one day, the authoritative vendor advisory for a CVSS 10.0 identity-service flaw carried an incorrect exploited flag, and the security press did what the security press does with a perfect-10 marked exploited.
The Register ran it. Secarma ran it. Cybersecurity Dive ran it. Several of those pieces have not been updated. The Hacker News did correct theirs, appending a note that Microsoft changed the flag after they sought comment — which is what the process is supposed to look like.
Why this is a story
Three reasons, in ascending order of importance.
First, the practical one. Somewhere right now a security team is being asked about a CVSS 10.0 Entra ID vulnerability under active attack, and the honest answer — it was never exploited, Microsoft already fixed it, there is nothing to do — sounds like deflection to anyone holding a printout of an uncorrected article. Bad information costs real time.
Second, the number is doing work it shouldn’t. Microsoft published temporal metrics alongside the base score that almost nobody carried: E:U/RL:O/RC:C — exploit code maturity Unproven, remediation level Official Fix, report confidence Confirmed — producing a temporal score of 8.7. Microsoft’s own fuller assessment was meaningfully less alarming than the number in the headlines, and Microsoft published both. The base score alone was never the whole record.
Third, and this is the one that generalizes. The vendor advisory is the primary source, and the primary source moved. Publications that treated a point-in-time read of MSRC as a permanent fact ended up permanently wrong. Advisories are living documents — Broadcom’s vCenter advisory reached revision .2 and added patch guidance for an entire version branch three weeks after publication; PaperCut’s build numbers still do not appear on its own release pages. Reading an advisory once and filing the story is not the same as sourcing it.
That is a workflow problem, not a competence problem, and it is going to get worse as the volume of disclosure grows. The counter is unglamorous: check when the record was last revised, and go back before you cite it.
Cloud CVEs are new, and they confuse people
Worth understanding the mechanism that produced this advisory, because you will see more of them.
Historically a CVE meant something you could install a fix for. Cloud providers fixed their own services quietly and told nobody, on the reasoning that there was no customer action to communicate. That changed as the industry pushed for transparency about flaws in services that customers depend on but do not control, and Microsoft now publishes CVEs for cloud-service issues it has already remediated, tagged exclusively-hosted-service.
This is a genuine improvement. It is also a reliable source of confusion, because these advisories look identical to the ones that require action. Same CVE format, same severity scores, same MSRC page layout, same vulnerability scanners ingesting them. The only signal that there is nothing to do is a “Customer Action Required: No” field and an FAQ entry, both easy to skip when a 10.0 is on the screen.
The practical consequence lands on whoever runs your vulnerability management program. A CVSS 10.0 flowing into a scanner or a risk register does not carry the “already fixed, nothing to install” context with it, and someone has to notice. If your process cannot distinguish a cloud-service transparency CVE from a patchable one, this will not be the last time it generates a fire drill.
What to do
- Nothing, for this vulnerability. There is no customer-installable fix, no build number, no configuration change. Any advice you see to “update Entra Connect” or “apply the Entra ID patch” is fabricated — there is nothing to apply.
- If this reached your leadership as an active-exploitation story, correct it, and point at MSRC revision 1.1 rather than at us.
- Add a revision check to how your team consumes advisories. MSRC, VMSA, and vendor KB articles all carry revision histories, and they change more often than the coverage built on them does.
- Be wary of a base score quoted without its temporal metrics when the vendor published both.
Sourcing note
Everything above comes from Microsoft’s own records: the MSRC advisory and its revision history, the CNA record at CVE.org, and NVD’s mirror of Microsoft’s data. The CVSS 10.0 is Microsoft’s own CNA score and NVD has produced no independent primary score. We could not verify when the service-side fix was actually deployed relative to the 20 August disclosure — Microsoft says only that it was mitigated before publication and gives no date, so we are not implying a window of exposure. No discoverer is credited in the MSRC record or the CVE record. Not in CISA KEV; CISA’s enrichment record sets exploitation to none. The characterization of which outlets have and have not corrected their coverage reflects their state at the time of writing.