Entra ID RCE: six CVSS 10.0 CVEs you cannot patch

On 2026-08-20, Microsoft released a batch of cloud-service CVEs. Thirteen of the Microsoft-issued records released between 2026-08-19 and 2026-08-25 carry a CVSS base score of 9.0 or higher. Six are exactly 10.0 — including CVE-2026-69836, in Entra ID itself — and all six landed that same day.

Your patch-compliance report for that week shows nothing: no KB number, no cumulative update, no maintenance window, no line item to close. Every one of the six records carries the field customerActionRequired: false, and Microsoft's FAQ on each one says it verbatim: “This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take. The purpose of this CVE is to provide further transparency.”

That is the point. Contrast it with the KEV entries you can patch, where installing the update is the whole job. A patch-compliance report is structurally blind to the identity control plane, because it measures the things you can install. Six critical defects in Microsoft-operated services your tenant depends on — including the platform it authenticates against — were found, fixed, and disclosed without your patching process ever having an opinion about it. A green patch dashboard did not tell you that you were safe that week. It gave you no signal at all.

The six CVSS 10.0 CVEs Microsoft published on August 20, 2026

Microsoft's descriptions, taken from the records rather than paraphrased:

• CVE-2026-69836 — Microsoft Entra ID Remote Code Execution Vulnerability, CWE-502. “Deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network.”
• CVE-2026-65801 — Microsoft Exchange Online Elevation of Privilege Vulnerability, CWE-918. “Server-side request forgery (ssrf) in Microsoft Exchange Online allows an unauthorized attacker to elevate privileges over a network.”
• CVE-2026-65816 — Azure Arc Elevation of Privilege Vulnerability, CWE-706. “Use of incorrectly-resolved name or reference in Azure Arc allows an unauthorized attacker to elevate privileges over a network.”
• CVE-2026-69555 — Azure Arc Elevation of Privilege Vulnerability, CWE-863. “Incorrect authorization in Azure Arc allows an unauthorized attacker to elevate privileges over a network.”
• CVE-2026-69502 — Azure SQL Database Elevation of Privilege Vulnerability, CWE-918. “Server-side request forgery (ssrf) in Azure SQL Database allows an unauthorized attacker to elevate privileges over a network.”
• CVE-2026-65770 — Azure Managed Instance for Apache Cassandra Remote Code Execution Vulnerability, CWE-88. “Improper neutralization of argument delimiters in a command ('argument injection') in Azure Managed Instance for Apache Cassandra allows an unauthorized attacker to execute code over a network.”

Read that as an inventory of control planes, not products: Entra ID decides who everyone is, Exchange Online holds the business record, and Azure Arc reaches onto servers in your own rack.

Why these Azure and Entra ID CVEs score 10.0

CVE-2026-69836's vector, which four of the six share exactly: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C. Component by component:

• AV:N — network reachable, from anywhere the service answers.
• AC:L — low complexity. No race to win, no configuration to hope for.
• PR:N — no privileges required. The attacker does not need an account.
• UI:N — no user interaction. Nobody has to click anything.
• S:C — scope changed. The impact escapes the vulnerable component's own security boundary.
• C:H/I:H/A:H — total impact to confidentiality, integrity, and availability.

S:C is what pushes these to 10.0 rather than 9.8: under CVSS 3.1 a scope-changed vector with no privileges and no interaction runs past the cap. The flag is the difference between “something bad happens to this service” and “something bad happens to whatever this service has authority over” — which, for an identity provider, is the tenant.

The impact metrics are not identical across the six. CVE-2026-69502 and CVE-2026-69555 are A:N — no availability impact at all — and still score 10.0, because scope change plus C:H/I:H is enough on its own.

Why you cannot patch a cloud-service CVE: the exclusively-hosted-service tag

You cannot. There is no update, no KB number, and no maintenance window, because the defect is in software Microsoft runs rather than software you installed. The CVE Program has a tag for exactly this case.

All six records carry the CVE Program tag exclusively-hosted-service. The tag exists to mark a defect in something the vendor runs, where the customer has no artifact to update. There is no meaningful affected version range — the MITRE record for CVE-2026-69836 lists the affected version as -.

Microsoft issues these under a deliberate transparency policy, and each record says so in its own words — the FAQ closes with “The purpose of this CVE is to provide further transparency.” Before that policy, defects like these were fixed silently and customers never learned they had existed. Publishing them gives you something to reason about, even though it gives you nothing to install.

The consequence: these CVEs never appear in your scanner's findings, because a scanner enumerates software you are running, and never in your patch report, because there is no patch. If your only vulnerability process is scan-then-patch, this class of risk is invisible by construction — and it sits closest to your identity boundary.

What a mid-market shop actually controls here

You cannot patch Entra ID. You can decide what an attacker who reached your tenant would be able to do with it, and whether you would be able to tell afterward — which is the substance of Entra ID and hybrid identity hardening. None of it is new work; it is work a patch dashboard never asks about.

Privileged role hygiene

Count your Global Administrators. If the number is above five, that is the first finding. Move standing assignments to eligible-only with approval and time limits, which is control two of the four in the mid-market AD Tier-0 plan, administer from cloud-only accounts with no mailbox, and never let a daily-driver account carry a directory role. Treat Application Administrator, Privileged Role Administrator, and Cloud Application Administrator as seriously as Global Admin. Each is a path back to it.

Conditional access

Require phish-resistant authentication for every directory role, not just MFA. Block legacy authentication protocols outright. Scope administrative access to compliant or hybrid-joined devices. Then read the policy set for exclusions and ask who added each one, and when — exclusion lists are where conditional access quietly dies.

Break-glass accounts

Two cloud-only accounts, excluded from conditional access by design, credentials split and stored physically, alerting on any sign-in, tested on a schedule. An untested one is a documented assumption, not a control.

Service principals and app consent

This is the one most mid-market tenants have never audited. Inventory enterprise applications and app registrations, and look specifically at credentials added to existing applications — a certificate or client secret attached to an app that already holds broad Graph permissions is persistence that survives a password reset. Restrict user consent to verified publishers and low-impact permissions, turn on the admin consent workflow, and review anything holding Directory.ReadWrite.All, Application.ReadWrite.All, or RoleManagement.ReadWrite.Directory.

Sign-in and audit log monitoring

Default retention in Entra ID is short, and it is not an archive. Export sign-in and audit logs somewhere with real retention, and alert on the events that matter: directory role assignment, credential addition to a service principal, federation and domain configuration changes, consent grants, and conditional access policy modification.

Session and token policy

Enable continuous access evaluation so revocation is closer to real time than to an hour, set sign-in frequency for privileged sessions, and know how long a tenant-wide refresh-token revocation actually takes — mid-incident is a poor time to find out.

Azure Arc specifically

Two of the six are Arc. Arc is not a monitoring tool; it is a control plane with an extension mechanism that executes code on the machines it manages, on-premises servers included. Audit who holds Azure Connected Machine Onboarding and Resource Administrator, restrict extension deployment, and treat Arc-enabled servers as inside your identity blast radius, because they are.

Azure SQL Database

Prefer Entra-only authentication over SQL logins, use managed identities rather than connection strings, close the “allow Azure services” firewall shortcut, and put production behind private endpoints.

The honest caveat

This is a posture argument, not an incident. All six records read exploited: No and publiclyDisclosed: No. CVE-2026-69836's record was revised on 2026-08-21, and the revision note reads verbatim: “Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only.” CISA's enrichment carries the same assessment on all six — Exploitation: none.

Five of the six carry E:U, meaning exploit code is Unproven. One does not. CVE-2026-69502, the Azure SQL Database SSRF, carries E:P — Proof-of-Concept exploit code exists. It is the only one of the six not marked Unproven, and that is worth saying plainly rather than letting a summary flatten all six into “no known exploit.”

All six also carry RL:O (Official Fix) and RC:C (Confirmed), which is why Microsoft's published temporal scores land below the base: 8.7 for five, and 9.0 for CVE-2026-69502 — the higher figure a direct consequence of that E:P. CISA's enrichment also flags all six as Automatable: yes, technical impact total. That is the honest counterweight to “unproven.”

One precision point, because coverage muddles it: this was an out-of-band cloud batch on 2026-08-20, not Patch Tuesday — that was 2026-08-11, a separate release with its own on-premises content. Conflating the two produces a CVE count no two trackers agree on.

What to tell the board

When someone forwards a headline about an Azure CVSS 10 and asks whether you are exposed, the answer has three parts, none of them “we patched it.”

First: there was nothing to patch. These were defects in Microsoft-operated services, fixed before disclosure and published for transparency. The correct response is to read it, not to schedule a window.

Second: the score is a severity ceiling, not a statement about your tenant. A 10.0 with scope changed says what the defect could reach in the abstract. What it could have reached in your environment is a function of how many standing Global Admins you carry, how many service principals hold write access to your directory, and whether your logs would still show any of it thirty days later. Those are your numbers.

Third: the useful exercise is the tabletop, not the ticket. Assume a defect of this class had been exploited against your tenant before the fix shipped. What reaches your data? What reaches your on-premises estate through Arc? What evidence survives? If you cannot answer those three with specifics, that gap is the finding — and no patch report will ever raise it, in any month, for any vendor.

If you would rather have a senior engineer run that tabletop, count the standing directory roles, and audit the service principals holding write access to your tenant, the project intake form takes about three minutes. Two-business-day response with scope and a fixed-fee range.

Patch compliance remains necessary and remains insufficient, and these six records show exactly where the insufficiency lives. Engineering time is better spent on the identity control plane than on a KB number that does not exist. The records are public: the MSRC Security Update Guide entry for CVE-2026-69836 and the corresponding CVE Program record are the sources for everything quoted above.