Microsoft Patches Perfect-10 Entra ID Flaw Already Under Attack

Microsoft has patched a maximum-severity vulnerability in Entra ID — the cloud identity service that decides who is allowed to sign in to Microsoft 365 and thousands of other business applications — after confirming that attackers had already found it and were using it. The flaw is tracked as CVE-2026-69836, carries a CVSS base score of 10.0, the highest the scale permits, and was disclosed on Thursday 20 August 2026. Because Entra ID is Microsoft-operated cloud infrastructure rather than software an organisation installs and maintains, Microsoft was able to fix the vulnerable service itself. There is no update to deploy, no reboot to schedule and, the company says, no customer action required at all.

That is where the reassurance stops. Microsoft has not said who exploited the flaw, when the attacks started, how many tenants were touched, or what the attackers were able to reach once they were in. It has published no indicators of compromise, no technical description of the attack chain and no guidance for organisations wanting to check their own logs. For a UK business, the practical consequence of a silent cloud fix is uncomfortable: the hole is closed, but there is no supplied way to answer the only question that matters to a board or an auditor — was our tenant affected during the window in which this was being exploited? This article sets out exactly what Microsoft disclosed on 20 August 2026, why a 10.0 in the identity layer is a different class of problem from a 10.0 in an ordinary application, and what a UK SME can reasonably do about a vulnerability it was never able to patch.

What Microsoft actually disclosed

The advisory published on Thursday 20 August 2026 describes a deserialization of untrusted data weakness in Entra ID, the service formerly known as Azure Active Directory. Deserialization flaws arise when a system takes structured data supplied from outside — a token, a request body, an encoded object — and reconstructs it into live objects in memory without adequately validating what it has been handed. Where the receiving code can be steered into instantiating attacker-chosen types or invoking attacker-influenced methods during that reconstruction, the result is not merely bad data but attacker-controlled execution. In this case Microsoft states the outcome plainly: remote code execution.

The severity rating is worth reading carefully rather than glancing at. A CVSS score of 10.0 is not simply “very bad”; it is a specific arithmetic result that requires effectively every base metric to sit at its worst available setting simultaneously. Microsoft’s assessment describes an attack that can be launched over the network, with low attack complexity, requiring no privileges whatsoever and no interaction from any user, and delivering high impact to confidentiality, integrity and availability alike. In other words: an unauthenticated stranger, reliably, with nobody clicking anything. Reaching a full 10.0 additionally requires that the impact cross the boundary of the vulnerable component itself — that compromising the flawed service lets an attacker affect resources beyond it. In an identity provider, that is close to a definition of the worst case, because the resources beyond the identity provider are every application that trusts it.

Microsoft credited the discovery and report to Robert Fitzpatrick, a principal security engineer. The advisory does not, however, explain the relationship between that report and the exploitation Microsoft says it observed — whether the researcher found a flaw that was independently already in use, whether the exploitation was detected first and the analysis followed, or whether telemetry revealed the activity after the report prompted a search. That distinction matters for anyone trying to estimate the exposure window, and it is precisely the detail the advisory omits. What Microsoft has confirmed is the combination that security teams treat as an emergency in any other context: maximum severity, no authentication required, and confirmed exploitation before disclosure.

How the story unfolded

Why the score reached a perfect 10.0

It is genuinely rare for a vulnerability to score 10.0. Most serious flaws lose fractions somewhere — they need a valid account, or a user to open something, or a particular configuration, or they only break confidentiality without touching integrity. CVE-2026-69836 lost nothing. Each of the base metrics that feed the score sits at its most severe available value, which is what the chart below shows: not seven different measurements of risk, but seven consecutive worst cases stacked on top of one another.

Read individually, each of those lines is a familiar phrase from a hundred advisories. Read together, they describe something specific and unpleasant: a vulnerability that could be triggered remotely by someone with no account and no foothold, that did not depend on tricking an employee, that was not difficult to pull off reliably, and that once triggered gave the attacker the ability to read, alter and disrupt. Add the eighth metric — impact extending beyond the vulnerable component into the systems that depend on it — and the arithmetic arrives at the ceiling. The scale simply has nothing worse to express.

Every metric at maximum

The clearest way to communicate this to a non-technical board is not to quote a vector string but to state the proportion. Of the base metrics that determine severity, the share sitting at their worst possible value is not most of them, or nearly all of them. It is all of them.

There is a second reason the number lands harder than usual. In the ordinary run of maximum-severity flaws — an unauthenticated RCE in a VPN appliance, say, or an edge file-transfer product — the score describes what an attacker can do to one system, and the containment conversation begins with network segmentation, asset inventory and which boxes are internet-facing. None of those levers apply here. The vulnerable component was not on your network and was never in your asset register; it is the service that issues the credentials your network trusts. The usual first question of incident response — which of our systems were exposed? — has an answer that no customer can independently produce, because the exposed system belonged to Microsoft and the telemetry describing the attack has not been shared.

Where UK SMEs are most exposed when identity is the target

Nothing in this incident was a customer misconfiguration, and it would be wrong to imply otherwise. But an identity-layer incident does expose which organisations are in a position to investigate one and which are not, and that difference is entirely within customer control. The grid below reflects the gaps we see most often in UK SME Microsoft 365 tenants when a question like “can we show what happened in our tenant in the first week of August?” is asked for the first time.

Each of those rows is worth a sentence of explanation, because the reasoning is not always obvious. Log retention comes first because it is the only one that cannot be fixed retrospectively: if the records for a given fortnight have already aged out, no amount of later diligence brings them back, and the question of whether your tenant was touched during an undisclosed exploitation window becomes permanently unanswerable. Conditional access sits next because it is the control that continues to apply even when a token is presented — policies keyed on device compliance, location and application do not stop a flaw in the identity service, but they narrow what a stolen or forged assertion can subsequently be used for. Administrative account hygiene matters because privileged identities are the pivot point in almost every post-authentication attack, and an admin account used for email and browsing is exposed to every ordinary risk on top of its privileges.

Further down the list, the items shift from prevention to visibility. Keeping an independent copy of identity telemetry — exported into a system that does not depend on the tenant itself — means an investigation is not conducted using only the logs of the platform under investigation. Maintaining an inventory of every third-party application federated to Entra ID answers the question “what else would have been reachable?” without a week of discovery work. Reviewing guest and dormant accounts closes the quiet accumulation of identities nobody owns. And a tested break-glass procedure — the one item most likely already to be in reasonable shape — is what stops an identity provider problem becoming a total loss of access to your own environment.

What identity hardening costs a UK business

The honest framing for this incident is that nothing on the list below would have prevented CVE-2026-69836, because the flaw was in Microsoft’s infrastructure and Microsoft fixed it. What this work buys is the ability to answer questions about your own tenant when a vendor declines to answer them for you, and to limit what any compromised assertion can reach. The bands below are indicative annual figures for UK organisations at typical sizes, covering identity configuration review, log retention and monitoring, and the ongoing administration that keeps both current. Actual costs depend on licensing, estate complexity and how much is already in place.

Two observations about those numbers. First, a substantial share of the work at the smaller bands is configuration rather than expenditure — enforcing MFA on every account, separating administrative identities and reviewing conditional access are licensing-permitting changes, not purchases, and the cost is largely the time to do them properly and the discipline to review them again. Second, the step change between bands is driven less by headcount than by the number of systems federated to the identity provider. A twenty-person business with fifteen SaaS platforms wired into single sign-on has a wider identity blast radius than a sixty-person business with three, and should be budgeting accordingly.

Reactive versus proactive identity posture

The gap between those two columns is not primarily a technology gap. Nearly every control in the right-hand column is available within the Microsoft 365 and Entra ID licensing that UK SMEs already hold, or is a modest step up from it. The gap is one of ownership: someone has to decide that identity is a system requiring active administration rather than a setting configured once during migration and then left alone. In practice that is what separates the organisations that spent 21 August calmly checking their own sign-in logs from the ones that spent it establishing that they no longer had any.

At a glance

The wider pattern this fits into

This is the third distinct shape of cloud-era risk we have covered in a fortnight, and the three are worth reading together. When the NCSC published its interim advice on managing the cyber risk of agentic AI, the underlying warning was about handing autonomy to systems whose failure modes you have not modelled. When Clop was linked to a breach of PLM software affecting major enterprises, the lesson was that a single upstream product can carry an incident into every organisation that uses it. CVE-2026-69836 is the same argument applied to the layer beneath both: not a tool you deployed or an agent you configured, but the service that decides whether anyone is allowed in at all.

The commercial version of the same dependency shows up in our coverage of the Harvest pricing increase, where the problem was not a security failure but a loss of control over a system the business could not easily leave. Infrastructure decisions carry the same logic: as Openreach’s XGS-PON rollout pushes more business function onto connectivity you do not own, and as social-engineering techniques grow more capable — the AI photo-geolocation scam targeting business travellers being a recent example — the practical question for a UK SME is consistently the same. Not whether to depend on external providers, which is no longer a real choice, but what you retain the ability to see, verify and control when one of them has a bad week and tells you very little about it.

Frequently asked questions

CloudSwitched

London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.