A CVSS 10.0 Flaw in Entra ID, and Nothing for Customers to Patch
- 4 days ago
- 3 min read
Microsoft disclosed a remote code execution flaw in Entra ID on 20 August carrying a CVSS score of 10.0, the highest the scale allows. By the time the advisory went live, the fix was already deployed and there was nothing for customers to install. Maximum severity paired with zero customer action is an unusual combination, and it is worth sitting with rather than filing away.
What Happened
The vulnerability, tracked as CVE-2026-69836, is a deserialization of untrusted data issue in Entra ID, Microsoft's cloud identity service and the successor to Azure Active Directory. Microsoft's advisory states that "deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network", with no authentication and no user interaction required. It was found internally by Microsoft Principal Security Engineer Robert Fitzpatrick, and because Entra ID is a fully managed service, Microsoft remediated it on its own infrastructure. There is no KB article, no update package and no configuration change for administrators to apply.
There is a second detail that deserves attention. The original security bulletin recorded the flaw as exploited in the wild. On 24 August Microsoft changed the exploitation status to "no" and confirmed to Help Net Security that the vulnerability had not been exploited, without explaining the reversal. Microsoft has provided no exploitation timeline, no customer impact detail and no technical description of the affected endpoint.
Why It Matters
Entra ID sits underneath Microsoft 365 and Azure for a large share of Australian enterprises, government agencies and mid-market businesses, and it acts as the identity provider for a long tail of third-party SaaS applications behind them. An unauthenticated code execution flaw in that layer sits below every Conditional Access policy, every MFA prompt and every tenant boundary an organisation has configured. Australian security teams found out about it after it was closed, could not verify anything independently, and then watched the exploitation status change three days later.
When the identity plane belongs to someone else, incident response starts with a vendor advisory your team had no part in writing.
What Security Teams Should Do Now
Map every system that trusts Entra ID for authentication, including SaaS applications using it as an identity provider. Most asset registers badly understate this.
Extend Entra ID sign-in and audit log retention past the default window and export it to your SIEM. When a fix happens on the provider's side, your own logs are the only record you control.
Review standing Global Administrator assignments, dormant privileged accounts and service principals holding permissions nobody has justified recently.
Confirm Conditional Access covers legacy authentication protocols, service accounts and non-interactive sign-ins, not just interactive user logins.
Track cloud service CVEs deliberately. They never surface in patch management tooling, because there is nothing to patch, so they fall out of standard vulnerability reporting.
Run a tabletop exercise on the assumption that an identity provider compromise comes with no advance notice and no patch to deploy.
Aurian's Take
Cloud service CVEs sit awkwardly in most vulnerability management programmes. There is no artefact to scan for, no version number to compare and no remediation ticket to close, so the finding gets acknowledged and then quietly drops out of the reporting cycle. The consequences do not drop out with it. Under the shared responsibility model the provider owns the fix, but the organisation still owns the breach notification, the OAIC assessment and the conversation with its board. CVE-2026-69836 shows how little an organisation can independently verify about the platform its entire access control rests on, and the shifting exploitation status makes that gap concrete rather than theoretical.
The practical response is to concentrate on the part of the identity estate you do control, because that is where attackers have been succeeding anyway. Aurian's penetration testing work regularly turns up over-permissioned service principals, app registrations left behind by decommissioned projects, Conditional Access rules with exemptions nobody remembers granting, and escalation paths that take a single low-privileged account to tenant-wide access. None of those require a CVSS 10.0 flaw to exploit. A cybersecurity assessment that models what an attacker does after gaining a foothold in your tenant gives you something a vendor advisory cannot: evidence about your own configuration, tested rather than assumed.
Microsoft closed this one before anyone outside Redmond knew it existed, and that is the system working as designed. The harder question for Australian security teams is what their own tenant looks like on the day the fix has to come from inside the organisation.
Comments