On August 20, 2026, Microsoft disclosed CVE-2026-69836 — a remote code execution vulnerability in Microsoft Entra ID with a CVSS score of 10.0. The maximum possible.

Then it got complicated.

What the vulnerability is

The root cause is CWE-502: deserialization of untrusted data. Entra ID was processing attacker-supplied input and converting it into active object structures without sufficient validation.

The CVSS vector is about as bad as it gets:

  • Network-reachable — no physical or local access needed
  • No authentication required
  • No user interaction — fully automated exploitation possible
  • Low attack complexity
  • High impact on confidentiality, integrity, and availability

An attacker who successfully exploited this could execute arbitrary code within Microsoft’s Entra ID infrastructure — meaning potential access to token issuance logic, service principal configurations, and federation trusts.

The disclosure mess

Microsoft’s initial security bulletin tagged the vulnerability as Exploited: Yes — active exploitation in the wild confirmed. That triggered incident response procedures across thousands of enterprise security teams.

Then, on August 21, following an inquiry from The Hacker News, Microsoft quietly updated the bulletin to Exploited: No — with no explanation of what changed or why the initial assessment was wrong.

As of August 25, 2026, Microsoft has not shared:

  • Whether there were actual confirmed attacks or if it was a labeling error
  • Any indicators of compromise
  • The discovery timeline
  • Technical detail about the attack method

The real issue: trust-but-cannot-verify

Microsoft’s message to customers is: we fixed it on our end, you do not need to do anything.

And that is technically true — Entra ID is SaaS. Microsoft controls the infrastructure. When they patch server-side, the fix applies globally.

But you have no way to verify any of it. You cannot check which version of Entra ID is running. You cannot audit whether the patch was actually applied to your tenant. You cannot independently confirm whether your environment was affected during the exposure window.

This is not a criticism of Microsoft specifically. It is a structural reality of SaaS identity infrastructure. When your IAM control plane is managed by a third party, your ability to independently verify your own security posture is fundamentally limited.

What you can actually do

1. Audit sign-in logs for the exposure window

Connect-MgGraph -Scopes "AuditLog.Read.All"

Get-MgAuditLogSignIn -Filter "createdDateTime ge 2026-08-01" |
    Where-Object { $_.RiskLevelDuringSignIn -ne "none" -or $_.RiskLevelAggregated -ne "none" } |
    Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName, RiskLevelDuringSignIn, Status |
    Sort-Object CreatedDateTime -Descending

Look for sign-ins from unexpected locations, unusual applications, or service accounts that do not normally authenticate interactively.

2. Verify service principal configurations

Get-MgServicePrincipal -All |
    Where-Object { $_.PasswordCredentials -or $_.KeyCredentials } |
    Select-Object DisplayName, AppId,
        @{N='CredentialExpiry'; E={ ($_.PasswordCredentials + $_.KeyCredentials).EndDateTime }} |
    Sort-Object CredentialExpiry

Flag any service principal with credentials added during the exposure window that you cannot account for.

3. Check federation trust configurations

Get-MgDomain | Where-Object { $_.AuthenticationType -eq "Federated" } |
    Select-Object Id, AuthenticationType, IsVerified

Verify no unexpected federated domains have been added.

4. Review Conditional Access policy changes

Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge 2026-08-01 and category eq 'Policy'" |
    Where-Object { $_.ActivityDisplayName -match "conditional access" } |
    Select-Object ActivityDateTime, ActivityDisplayName, InitiatedBy, Result

Bottom line

CVE-2026-69836 is patched. You do not need to apply anything.

But the disclosure itself is a useful reminder of two things.

First, CVSS 10.0 in your identity plane is a different category of risk than CVSS 10.0 in an application server. Entra ID is not just another service — it is the trust anchor for everything else in your Microsoft environment. A compromise there is a compromise everywhere downstream.

Second, SaaS security is not the same as no security responsibility. You cannot patch it, but you can audit your own tenant for anomalies, verify your configurations are as expected, and maintain logging practices that would surface something unusual. Detection capability matters even when you cannot control the patch.

References