Cloud Security Wire
AWS Azure GCP RSS
Azure CVE Analysis critical

CVE-2026-69836: Inside the CVSS 10.0 Entra ID Deserialization RCE

Microsoft disclosed a maximum-severity remote code execution flaw in Entra ID caused by unsafe deserialization. No patch is needed on your end, but the incident is a hard reminder to instrument identity logging before the next one isn't silently fixed for you.

By Editorial Team · ·
#entra-id#azure-ad#CVE-2026-69836#deserialization#identity-security#conditional-access#sentinel#CWE-502
Critical Severity

This issue has been assessed as critical severity. Review affected configurations immediately.

Overview

On August 20-21, 2026, Microsoft published CVE-2026-69836, a remote code execution vulnerability in Entra ID (formerly Azure AD) with a CVSS 3.1 base score of 10.0 — the maximum possible rating. The flaw is rooted in CWE-502, deserialization of untrusted data: a service endpoint accepted attacker-controlled serialized objects and reconstructed them without adequate validation, which under the right conditions let an unauthenticated, remote attacker execute arbitrary code with no user interaction required.

Because Entra ID is a fully managed cloud service, there is no patch for tenant admins to apply. Microsoft fixed the flaw server-side across its infrastructure before publishing the advisory and says the issue “has already been fully mitigated” with “no action for users of this service to take.” The disclosure itself is notable: Microsoft initially flagged the CVE as exploited in the wild, then revised that field days later to say it had not been exploited, without publishing an explanation for the correction. Coverage from Cybersecurity Dive, The Hacker News, and Help Net Security all confirm the same sequence — an initial “exploited: yes” marking walked back to “no” after press inquiries.

That inconsistency, more than the bug itself, is the operationally relevant part of this story. A CVSS 10.0 identity-plane RCE with conflicting exploitation signals and zero IOCs from the vendor means defenders can’t independently confirm whether their tenant was touched. The only real mitigation available to you is making sure your own telemetry would catch it if it happens again.

Why deserialization bugs are so dangerous in identity services

Deserialization vulnerabilities occur when a service reconstructs objects from untrusted byte streams (JSON, XML, binary formats) without restricting which types can be instantiated or validating the resulting object graph. If an attacker controls the serialized payload, they can often smuggle in “gadget” objects whose constructors or property setters trigger unintended code paths — file writes, reflection calls, or direct command execution — during reconstruction, before any application-level authorization check ever runs.

In a token-issuing identity provider like Entra ID, that class of bug is uniquely severe: successful exploitation sits upstream of every application, API, and workload that trusts Entra-issued tokens. It doesn’t matter how tightly you’ve scoped RBAC in a given subscription if the identity plane issuing your tokens is compromised first.

What tenant admins should actually do

Microsoft’s “no action required” framing is accurate for patching, but it doesn’t mean there’s nothing to do. Since you can’t verify server-side exploitation independently, treat this as a trigger to validate your own identity detection coverage.

1. Confirm sign-in and audit log retention is sufficient to investigate retroactively.

az monitor diagnostic-settings create \
  --name "entra-id-full-audit" \
  --resource "/providers/Microsoft.aadiam" \
  --logs '[{"category":"SignInLogs","enabled":true},
           {"category":"AuditLogs","enabled":true},
           {"category":"ServicePrincipalSignInLogs","enabled":true},
           {"category":"NonInteractiveUserSignInLogs","enabled":true}]' \
  --workspace "<log-analytics-workspace-id>"

2. Hunt for anomalous service principal creation or credential additions, since deserialization RCEs are frequently chained into token-forging or app-registration persistence.

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in (
    "Add service principal credentials",
    "Add application", 
    "Update application – Certificates and secrets management")
| extend actor = tostring(InitiatedBy.user.userPrincipalName)
| where isempty(actor)  // system/unattributed actors are the anomaly
| project TimeGenerated, OperationName, TargetResources, InitiatedBy

3. Enforce Conditional Access baselines so a compromised token has limited blast radius even if identity infrastructure is briefly untrustworthy.

resource "azuread_conditional_access_policy" "block_legacy_and_risky_sessions" {
  display_name = "Block legacy auth and require MFA for risky sign-ins"
  state        = "enabled"

  conditions {
    sign_in_risk_levels = ["high", "medium"]
    client_app_types    = ["all"]
    applications { included_applications = ["All"] }
    users { included_users = ["All"] }
  }

  grant_controls {
    operator          = "OR"
    built_in_controls = ["mfa", "block"]
  }
}

4. Alert on newly registered high-privilege app roles or Graph API permission grants — a common post-exploitation step after any identity-provider compromise:

AuditLogs
| where OperationName == "Add app role assignment to service principal"
| where TargetResources has_any ("Directory.ReadWrite.All", "RoleManagement.ReadWrite.Directory")

Takeaway

CVE-2026-69836 is a reminder that the most consequential cloud vulnerabilities are increasingly ones you can’t patch yourself — and the trust model that goes with that shifts the burden onto your own logging, retention, and anomaly detection. Vendor “fully mitigated, no action needed” statements should trigger a detection review, not a shrug.

Sources

← All Analysis Subscribe via RSS