A CVSS 10.0 With Nothing to Patch: Reading the Entra ID Advisory Properly
- Home
- Blog
I’m Joe. Last week produced a vulnerability with the highest score the scale allows, in a service almost every enterprise depends on, and there was nothing to install. That combination breaks the habits most security teams run on — the patch queue, the scanner report, the change window — so it is worth walking through carefully. This is about how to read an advisory like this, and what is genuinely worth doing in your own tenant.
-
What Was Published
On 20 August 2026 Microsoft published CVE-2026-69836, a remote code execution vulnerability in Microsoft Entra ID with a CVSS 3.1 base score of 10.0. The weakness class is CWE-502, deserialization of untrusted data: the service reconstructed objects from data an attacker could influence without validating it properly. The score is maximal because every modifier that could reduce it is absent — network reachable, low attack complexity, no privileges required, no user interaction, and impact spilling beyond the vulnerable component.
-
The Part That Confused Everyone
The advisory originally marked the “Exploited” field as Yes. A day later, on 21 August, Microsoft corrected it to No, stating the vulnerability had not been exploited in the wild. By then a number of outlets — and a number of internal incident channels — had already recorded “actively exploited, CVSS 10” and moved on. The practical lesson is unglamorous: an advisory is a living document for the first few days. Link to it, re-read it before you escalate, and record the timestamp of the version you acted on. Screenshot the fields you based a decision on, because they can change underneath you.
-
A CVSS 10.0 With Nothing to Install
Remediation was applied inside the service. There is no update to deploy, no version to verify, no reboot to schedule — Microsoft stated no customer action was required. This is what a cloud CVE looks like, and it does not fit the machinery most teams have built. Your vulnerability scanner will never see it. Your patch compliance report will never show it. Your change advisory board cannot approve it. The fix happened, on someone else’s timeline, and you found out afterwards. That is the actual deal in a shared-responsibility model, and it is worth saying out loud to leadership before the next one lands.
-
So Why Does It Still Matter to You?
Because “patched by the provider” and “nothing happened in my tenant” are two different statements, and only one of them was made. Entra ID is the front door to mail, files, code repositories and administrative consoles. A flaw at that layer does not need to touch your servers to matter. You cannot verify the fix, you cannot roll it back, and you cannot test it — so the only levers you hold are detection and blast radius. That is where the effort should go, and it is effort that pays off regardless of whether this particular CVE was ever used.
-
What I Would Actually Check This Week
Pull Entra sign-in and audit logs for the days around the disclosure and look for the things that survive a fix: new or modified application registrations, credentials or certificates added to existing service principals, consent grants nobody remembers approving, and role assignments made outside your normal change process. Confirm that privileged roles are eligible through PIM rather than permanently assigned, that break-glass accounts are excluded from Conditional Access but monitored closely, and that your logs are shipped somewhere the tenant itself cannot alter. If your retention is shorter than the time between disclosure and detection, that is your real finding.
-
The Rest of the Week Told the Same Story
The Entra advisory did not arrive in isolation. A threat actor publicly claimed to have taken millions of employee records associated with large enterprises through Azure environments — claims, at this stage, not confirmed findings, and worth treating as such. The FBI, CISA and HHS reported that the Medusa ransomware operation has now breached more than five hundred organisations. Citrix and GitLab both shipped critical fixes for products you host yourself, which means those are in your patch queue. Read as a set, the week said the same thing three times: the credential and the identity layer are the target, and the perimeter stopped being the interesting part years ago.
-
How to Read a 10.0 Without Panicking
A base score describes the vulnerability, not your risk. Four questions turn one into the other. Is it in my estate at all? Is the vulnerable path reachable from where an attacker actually stands? Who applies the fix — me or the provider? And if it were being exploited against me right now, what would I see, and would I still have the logs to see it in? Answer those four honestly and a 10.0 you cannot patch becomes a detection exercise instead of a fire drill. Answering them well is mostly work you have to do before the advisory shows up.
Comments (5)
-
ident_arch 1 day ago ReplyThe Exploited field flipping from Yes to No caused a genuine mess for us. We had already opened a P1 and told the board.
-
Not a wasted exercise. Record what you checked and how long it took — that is a free tabletop you did not have to schedule.
-
-
The retention point hits hard. Our sign-in logs roll off well before we would realistically detect something at that layer.
-
Explaining to auditors that a critical CVE has no patch evidence is its own special conversation. Bookmarking this for the next one.
-
Give them the provider statement plus your own detection review for the window. Evidence of looking is evidence.
-
-
Went through app registrations after reading this and found three service principals with certificates nobody could account for. All from 2023, but still.