REDMOND, 22 AUG 2026 — Microsoft disclosed on 21 August that a vulnerability in Entra ID, its cloud identity and access management service, carries a CVSS score of 10.0 and has been exploited in the wild. The flaw is a deserialisation of untrusted data that lets an unauthenticated attacker execute code over a network.
There is no patch to apply. Microsoft says the vulnerability has already been fully mitigated in its own infrastructure and that there is no action for users of the service to take. It states that the purpose of the CVE is to provide further transparency.
What the advisory says
The combination that produces a score of ten is specific and worth spelling out. An attacker needs no account on the target tenant, needs no credential, and needs nobody to click anything. The attack is reachable over a network against the service that decides who everyone else is.
Entra ID is the successor to Azure Active Directory and the identity layer beneath Microsoft 365, Azure and a large amount of third-party software that federates authentication to it. It is not an application. It is the thing applications ask when they want to know whether a request is legitimate.
The transparency is one bit wide
Microsoft framed the disclosure as an act of transparency, but the frame is larger than the picture.
The advisory establishes that a vulnerability existed, that it was severe, that it was exploited, and that it is now fixed. It does not establish who exploited it, when the exploitation began, whether it has stopped, how many tenants were affected, which tenants were affected, what the attackers did once inside, or what data they could reach.
For a security team, that set of facts boils down to a single, unhelpful conclusion: something happened, but you cannot find out if it happened to you. There are no indicators of compromise to hunt for. There is no log field to query. There is no version number to compare against a fixed build, because the build was never yours.
This is not a complaint about Microsoft withholding a patch. There was never a patch to withhold. It is an observation that the normal incident-response workflow — determine exposure, determine whether exploitation occurred locally, contain, remediate, document — has no first step here.
A cloud CVE is a different object from a software CVE
The CVE system was designed for software that customers run. A vendor ships a fix, customers apply it, and the interval between those two events is the window a defender is managing. Almost every process in vulnerability management — scanning, patch SLAs, exception registers, compensating controls — exists to shorten or survive that window.
None of it applies to a flaw in a service the vendor operates. The window opened and closed without the customer being present. By the time the CVE exists, the remediation has already happened, and the customer's role in the process is to read about it.
That is arguably a better outcome. A vendor that can fix its own infrastructure in hours beats a hundred thousand organisations patching over weeks, and the historical record of on-premises Exchange makes that argument for itself. But it changes what a CVE is for. This CVE is not an instruction, but a notification. The two require different responses.
It also means the customer cannot verify the vendor's account. Nothing here is checkable from outside Microsoft. The claims that the issue is mitigated and that no action is required rest on the same source as the silence about data access: Microsoft itself.
What a tenant can actually do
With no patch to apply, the reflex is to do nothing. But three things are still worth doing.
First, check log retention. Entra ID's default sign-in and audit log retention is finite — often weeks, not years. Organisations that export to a SIEM will have a longer history to check. If the exploitation window is later disclosed and it sits outside a tenant's retention period, that tenant will never be able to answer questions about it. Extending retention is a decision that has to be made before the disclosure, not after.
The second is blast radius. A compromise of the identity service is only as damaging as what identity grants, and the practical control is the standing privilege attached to accounts and service principals. Applications with consented permissions they no longer use, service principals with credentials that never expire and administrative roles held permanently rather than activated on demand all convert an identity-layer incident into a data incident.
The third is federation. Organisations that federate other systems to Entra ID have made it a single point of authority, and many have never enumerated what would be reachable if that authority were forged. That inventory is worth holding regardless of this specific flaw.
Why the identity plane makes this worse than the score suggests
A CVSS score measures the vulnerability, not the asset. Ten out of ten describes how easy the flaw is to exploit and how completely it compromises the affected component. It says nothing about what that component controls.
Deserialisation is a well-understood flaw class. An application accepts serialised data from an untrusted source, and an attacker who controls that input can influence what objects get constructed and, ultimately, what code gets executed. They are common, they are usually fixed by not deserialising untrusted input at all, and they turn up regularly in enterprise software.
What is unusual is the location. The same flaw class in a reporting tool produces a compromised reporting tool. In the service that issues tokens, the consequences depend entirely on what an attacker with code execution could reach from there, and Microsoft has not said. The absence of a statement that no customer data or tokens were accessible is conspicuous, though it is not evidence that any were.
What remains unconfirmed
The disclosure leaves most questions unanswered. Microsoft has not said who conducted the attacks, when they began, if they are ongoing, how they were detected, or how many tenants were affected. The advisory includes no indicators of compromise, no detection guidance, and no word on whether customer data, tokens, or credentials were accessible. We also do not know if affected tenants have been notified, or if regulators have been informed.
The CVSS vector string was not published alongside the score in the available reporting, and the relationship between the internal discovery credited to a Microsoft engineer and the observed exploitation — whether the flaw was found because attacks were noticed, or attacks were noticed because the flaw was found — is not described.
What to watch for
Watch for Microsoft to supplement the advisory. Naming an exploitation window would be the single most useful addition, as it would let organisations check whether their retained logs cover the period.
The second is whether individual tenant notifications appear. Customers being told privately that they were affected, while the public advisory says no action is required, is a materially different situation from one where nobody was reached.
The third is regulatory. Identity-layer compromise at a provider of this scale is the kind of event that data protection authorities ask about, and any enforcement correspondence would surface facts the advisory does not contain.
View author profile → · Editorial policy
