A CVSS 10.0 you cannot patch

Microsoft’s advisory for CVE-2026-69836 says there is no action for users of this service to take, because the vulnerability has already been fully mitigated [5].

CISA added the same CVE to its Known Exploited Vulnerabilities catalog the next day and gave federal agencies until August 24 [3].

Both of those are correct, which was not obvious to me, so I went to find out what a KEV deadline means for something you rent rather than run.

What happened

CVE-2026-69836 is a deserialization of untrusted data flaw in Microsoft Entra ID, the identity service formerly called Azure Active Directory. NVD scores it 10.0, network reachable, no authentication, no user interaction, and with a changed scope, meaning the impact reaches beyond the vulnerable component itself [2].

Ten is the ceiling. Very few things get there.

Microsoft published the advisory on August 20, 2026 and its machine-readable record marks customer action required as false [1]. BleepingComputer reports Microsoft confirmed the flaw has been exploited in attacks, and that exploit code is not publicly available [5]. Help Net Security is more careful, quoting only the mitigation statement, and notes Microsoft has not said who exploited it, when exploitation began, how many organisations were affected, or what the attackers achieved [6].

That list of unknowns is the whole story, so it is worth restating plainly. There is no affected component named. No dates. No indicators. No detection guidance.

The next day, CISA listed it with a three day deadline [3].

Why this matters

The vulnerability management model assumes the vulnerable thing is yours. Find the asset, apply the update, confirm the version, close the ticket. Every step of that assumes you own the code. Here you do not own it, cannot scan it, cannot version it, and cannot confirm anything about it. The entire apparatus has nothing to grip.

A fix is not an all-clear. Microsoft mitigating the flaw stops it being used from now on. It says nothing about the window when it was live, and Microsoft has not said how long that window was. If your tenant was touched during it, the accounts created are in your directory and the data that left was yours. Patching the service does not reach backwards.

This is where the shared responsibility model gets quiet. The provider is responsible for the security of the cloud, and they did that part: found it, fixed it, disclosed it. You are responsible for security in the cloud, and the consequences of somebody else’s flaw land squarely in that half. Nobody is breaking the deal. It is just that the half you own is where the work is, and it does not come with a patch to install.

Technical breakdown

This is the shortest technical section I have written, because Microsoft published almost nothing and I am not going to fill the gap with plausible narration.

What is known: deserialization of untrusted data, CWE-502, reachable over the network without credentials, resulting in code execution, with a scope change in the CVSS vector [2]. Deserialization flaws arise when a service reconstructs an object from data it received without adequately constraining what that data is allowed to become.

What is not known: which component, which entry point, what the attacker gained, and whether tenant boundaries were involved at all. The scope change in the vector says the blast radius crossed a security boundary, and Microsoft has not said which one.

There is no attack-chain diagram in this post. This blog puts one in every post that describes a sequence, and no sequence has been published. Drawing a speculative one from the vulnerability class would look authoritative and would be invention.

What CISA actually requires, which is not patching

This is the part I had not read before and the part that resolves the apparent contradiction. The KEV entry’s required action points at the cloud-service guidance in BOD 26-04 and at CISA’s forensic triage requirements, with a fallback of discontinuing use of the product where mitigations are unavailable [3].

The triage guidance sets out six steps: scoping, preserving and collecting evidence, critical patching and stabilisation, containment and control, triage analysis, and an escalation decision [4]. Two of those matter disproportionately here. Scoping asks agencies to determine whether a KEV addition requires triage to assess whether systems have been impacted. Evidence preservation asks them not to alter or remediate before collecting artifacts [4].

So the deadline is for completing a triage, not for installing anything. Read that way, a cloud CVE in KEV stops being a paradox. It is an instruction to go and look, on a clock.

The fallback deserves a moment of its own. Discontinuing use of the product is a real option for a niche appliance. For the identity plane of an entire estate it is not, and nobody is going to take it. Worth naming as theoretical rather than counting it as a control.

What defenders should do Monday morning

Immediate, within 24 hours. Nothing to patch, so start where the evidence is. Confirm you are retaining Entra sign-in logs and audit logs, and confirm the retention window actually covers the period before August 20, 2026. Default retention on lower licence tiers is short, and if the logs have rolled, the answer to whether anything happened is permanently unavailable rather than merely unknown.

Near term, this week. Review directory changes rather than sign-ins alone, because a deserialization flaw yielding code execution would not necessarily produce a failed login. Look at new or modified service principals and application registrations, consent grants, credentials added to existing applications, and changes to privileged role assignments. Anything you cannot tie to a change record is worth an explanation. This is generic identity-plane hunting rather than guidance specific to this CVE, and I am saying so because Microsoft published nothing that would let anyone be specific.

Structural, this quarter. Decide now what you would do the next time a provider discloses a fixed flaw with no indicators, because there will be a next time and the answer should not be improvised. That means knowing which logs you hold, how far back, and who reads them. Then read your provider contracts for what you are actually told after an incident in their service, and notice whether the answer is anything.

Checklist

• Entra sign-in and audit log retention confirmed, and confirmed to cover before August 20, 2026
• Retention extended or exported where the window is too short to answer questions
• Service principals and app registrations reviewed for unexplained additions or changes
• Credentials added to existing applications reviewed
• Consent grants and privileged role assignment changes reviewed
• Every unexplained identity object tied to a change record or investigated
• A written plan for provider-side incidents with no indicators
• Provider contract checked for what you are entitled to be told

The half of the model nobody drew

Shared responsibility diagrams are drawn as a clean split. The provider’s boxes sit at the bottom, yours sit on top, and a line runs between them. Every one of those diagrams answers the question of who fixes what.

None of them answer who finds out.

That is the gap this CVE sits in. Microsoft did its half correctly and quickly. The consequences, if there were any for your tenant, are in your half, and the only instrument you have is logs you may not be keeping long enough. The industry has spent a decade getting comfortable with the split without noticing that the detection half was never really assigned.

If your answer to “were we affected” depends entirely on a provider choosing to tell you, that is not a control. It is a hope with a contract attached.