A CVSS 10.0 alarm bell ringing in a building you don't own and the landlord already replaced the lock
CVE-2026-69836 is a CWE-502 deserialization-of-untrusted-data flaw in Microsoft Entra ID, the cloud-hosted identity service (formerly Azure AD) that handles authentication for Microsoft 365, Azure, and thousands of federated apps. An unauthenticated attacker who could reach the vulnerable deserialization endpoint could inject a malicious serialized object and achieve remote code execution *inside Microsoft's own infrastructure*. Microsoft has not disclosed which specific endpoint or serialization format was involved, nor the duration of the exposure window. The flaw was discovered internally by Microsoft Principal Security Engineer Robert Fitzpatrick and remediated server-side *before* the August 20, 2026 public disclosure. No customer-deployable patch exists or is needed.
Microsoft's vendor severity of CRITICAL (10.0) accurately reflects the *theoretical* blast radius — unauthenticated RCE in the planet's largest identity provider. But from an enterprise patch-management standpoint, the rating is profoundly misleading. This is an Exclusively Hosted Service vulnerability: the bug lived in Microsoft's cloud, Microsoft fixed it in Microsoft's cloud, and Microsoft explicitly states *"there is no action for users of this service to take."* Your vulnerability scanners will never flag it on your 10,000 hosts because it was never on your hosts. The initial advisory also marked the flaw as "Exploited: Yes" before Microsoft corrected this to "No" within hours — a disclosure-quality stumble that triggered unnecessary incident-response fire drills across the industry. CISA briefly added then removed it from KEV in the same window. The EPSS score of 1.5% is consistent with a vulnerability that cannot be weaponized against customer infrastructure.
4 steps from start to impact.
Identify the vulnerable deserialization endpoint
- Knowledge of the undisclosed vulnerable endpoint in Microsoft's Entra ID infrastructure
- Network reachability to that endpoint (public internet to Microsoft's cloud edge)
- The specific endpoint and serialization format are undisclosed — no external attacker has demonstrated knowledge of them
- Microsoft's own perimeter defenses (Azure Front Door, DDoS protection, WAF rules) sit between the attacker and the endpoint
Craft a malicious serialized payload
- Deep knowledge of the server-side technology stack and available gadget chains
- A deserialization format that permits object injection (e.g., .NET BinaryFormatter, Java ObjectInputStream)
- The target is a black-box cloud service — no binary, no JAR, no source to analyze
- The one GitHub repo (
sentinel-aidefense/CVE-2026-69836-EXP) contains no real exploit code and shows hallmarks of a fake/lure repository (2 commits, 0 forks, vague README)
Submit payload and achieve RCE in Microsoft's infrastructure
- Steps 1 and 2 succeed
- The endpoint has not yet been patched by Microsoft
- Microsoft remediated the flaw *before* public disclosure — the window is closed
- Even during the exposure window, exploitation would have occurred in Microsoft's infrastructure, not in customer environments
- Microsoft's internal detection and response (DART, SOC) would observe anomalous execution in their own service
Pivot from Entra ID service internals to tenant data
- Successful RCE in Microsoft's infrastructure (Step 3)
- Ability to bypass Microsoft's internal tenant isolation and service segmentation
- Microsoft's multi-tenant isolation is designed to prevent exactly this lateral movement
- Microsoft states the vulnerability was *not* exploited in the wild
- No tenant-level indicators of compromise have been published
- Scanning your hosts for this CVE — No vulnerability scanner (Qualys, Tenable, Rapid7, CrowdStrike) can detect this because the vulnerable code never ran on your infrastructure. If a scanner *does* flag it (some ingest NVD feeds without filtering by deployment model), suppress the finding with a documented exception.
- Applying a patch via WSUS/SCCM/Intune — No customer-deployable patch exists. This is not a Windows Update, not a .NET patch, not an agent update. The fix was applied inside Microsoft's cloud.
- Blocking network traffic to Entra ID endpoints — Entra ID is your identity provider. Blocking
login.microsoftonline.comorlogin.microsoft.comwould break all Microsoft 365 and Azure authentication for your entire organization. This is not a viable compensating control. - Rotating all user passwords — There is no evidence that credentials were compromised. A mass password reset would cause significant operational disruption with no security benefit, since the attack path (if it had been exploited) would have targeted Microsoft's infrastructure, not credential stores directly.
The supporting signals.
| In-the-Wild Exploitation | None confirmed. Microsoft initially marked the advisory as "Exploited: Yes" on August 20, 2026, then corrected to "No" on August 21. No exploitation evidence has been published by Microsoft, CISA, or third-party threat intel providers. |
|---|---|
| CISA KEV Status | Not listed. CISA briefly added CVE-2026-69836 to the Known Exploited Vulnerabilities catalog on August 21, 2026 (likely triggered by Microsoft's erroneous "Exploited: Yes" flag), then removed it within hours after Microsoft's correction. |
| Proof-of-Concept Availability | No legitimate PoC exists. One GitHub repo (sentinel-aidefense/CVE-2026-69836-EXP) claims to be an exploit but contains no working code — 2 commits, 0 forks, 1 star, vague README with a generic command template. A second repo (HORKimhab/CVE-2026-69836) is labeled "Draft or TODO." Both are likely lure/clout repos. No entries found on pocindex.io, ExploitDB, or Metasploit. |
| EPSS Score | 0.01532 (1.5%) — low probability of exploitation in the next 30 days, consistent with a cloud-only vulnerability that cannot be weaponized against customer infrastructure. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — the maximum possible score. Network-reachable, no auth, no interaction, changed scope, full CIA impact. Technically accurate *for Microsoft's infrastructure*, but inapplicable to customer environments since no customer-side attack surface exists. |
| Affected Versions | All pre-August 2026 releases of the Microsoft Entra ID cloud service. No version numbers published — this is a continuously deployed cloud service, not a versioned software product. |
| Fixed Versions | Server-side remediation completed before disclosure (August 20, 2026). No customer-deployable patch exists. Microsoft: *"This vulnerability has already been fully mitigated. There is no action for users of this service to take."* |
| Scanning / Exposure Data | Not applicable. GreyNoise, Shodan, and Censys cannot detect this vulnerability because it exists in Microsoft's cloud infrastructure, not in customer-facing assets. No vulnerability scanner (Qualys, Tenable, Rapid7) can flag this on customer hosts. |
| Discoverer | Robert Fitzpatrick, Microsoft Principal Security Engineer (internal discovery). No external researcher credit. |
| Disclosure Model | Microsoft's cloud-service CVE transparency policy — significant cloud vulnerabilities receive CVEs even when no customer remediation is necessary. This is a governance disclosure, not an actionable patch advisory. |
Sources.
- The Hacker News — Microsoft Entra ID Flaw CVSS 10.0
- Cybersecurity Dive — Microsoft discloses maximum severity flaw in Entra ID
- Help Net Security — Microsoft patches critical Entra ID vulnerability
- ComplianceHub — CVSS 10.0 You Cannot Patch: Governance Gap in Provider-Remediated Vulnerabilities
- Halfteck — Microsoft rated its own Entra ID bug 'exploited,' then walked it back
- Start With Identity — Microsoft Entra ID CVSS 10 Deserialization Flaw
- GitHub Advisory Database — GHSA-v6wh-624g-vvmv
- Windows Forum — CVE-2026-69836 Entra ID Flaw Was Not Exploited
Why this verdict
- No customer-side attack surface exists. The vulnerability is in Microsoft's cloud infrastructure. There are zero hosts in your fleet that run the affected code, zero patches to deploy, and zero configurations to change. Your vulnerability scanners will never report this finding on any of your 10,000 hosts.
- Already remediated by Microsoft before disclosure. The fix was deployed server-side before August 20, 2026. The exploitation window is closed. Even if an attacker had the knowledge and capability to exploit this, they can no longer do so.
- No confirmed exploitation. Microsoft corrected its own erroneous "Exploited: Yes" flag within hours. CISA removed the CVE from KEV in the same timeframe. No threat intelligence provider has reported exploitation activity. EPSS is 1.5%.
- No viable PoC. No working proof-of-concept exists publicly. The GitHub repos claiming exploit code are empty lures. The target is a black-box cloud service that cannot be reverse-engineered by external researchers.
- Role multiplier: Entra ID is canonically the highest-value identity component imaginable — it IS the identity provider for hundreds of millions of users. If this were a customer-deployed product, the floor would be CRITICAL without question. However, the deployment model fundamentally changes the analysis: customers do not deploy, operate, or patch Entra ID. The blast radius for a *customer* is zero controllable hosts. The blast radius for *Microsoft* was theoretically catastrophic, but Microsoft is the one who patched it, and they did so proactively. The floor rule is designed for vulnerabilities in software you run — this is a vulnerability in software your vendor runs.
- Governance, not patching. This CVE exists under Microsoft's cloud transparency policy. It is a notification that a risk existed and was resolved in your vendor's infrastructure. The appropriate response is compliance documentation, not a change window.
Why not higher?
Upgrading this to any actionable severity (LOW or above) would imply there is something for the enterprise defender to *do* — a patch to apply, a configuration to harden, a workaround to deploy. None of these exist. Microsoft has explicitly stated no customer action is required. Treating this as anything other than IGNORE in your patch-management workflow creates phantom work items that cannot be closed through technical action, distorts SLA metrics, and diverts attention from vulnerabilities you *can* actually fix.
Why not lower?
IGNORE is already the lowest severity in the noisgate framework. The only question is whether it deserves LOW (backlog hygiene), but LOW implies there is *eventually* something to patch. There is not. The correct disposition is document-and-close.
Crowdsourced verification payload.
Run this on an auditor workstation with the Microsoft.Graph PowerShell module installed and an account holding at least Reports Reader or Security Reader in Entra ID. Invoke with: ./Check-CVE-2026-69836.ps1 -TenantId "your-tenant-id". The script checks for anomalous sign-in activity during the plausible exposure window and reports whether your tenant shows indicators warranting deeper investigation.
#Requires -Modules Microsoft.Graph.Reports, Microsoft.Graph.Authentication
<#
.SYNOPSIS
CVE-2026-69836 exposure-window audit for Microsoft Entra ID.
.DESCRIPTION
Queries Entra ID sign-in logs for anomalous activity during the
plausible exposure window (2026-07-01 to 2026-08-20) before
Microsoft's server-side remediation.
Outputs: VULNERABLE (anomalies found) / PATCHED (no anomalies) / UNKNOWN (unable to query).
.PARAMETER TenantId
Your Azure AD / Entra ID tenant ID (GUID).
#>
param(
[Parameter(Mandatory)]
[string]$TenantId
)
$ErrorActionPreference = 'Stop'
$exposureStart = '2026-07-01T00:00:00Z'
$exposureEnd = '2026-08-20T23:59:59Z'
$anomalyThreshold = 5
try {
Write-Host '[*] Connecting to Microsoft Graph...' -ForegroundColor Cyan
Connect-MgGraph -TenantId $TenantId -Scopes 'AuditLog.Read.All','Directory.Read.All' -NoWelcome
} catch {
Write-Host "UNKNOWN - Failed to connect to Microsoft Graph: $_" -ForegroundColor Yellow
exit 2
}
try {
Write-Host "[*] Querying sign-in logs for exposure window ($exposureStart to $exposureEnd)..." -ForegroundColor Cyan
# Check for anomalous service principal sign-ins
$filter = "createdDateTime ge $exposureStart and createdDateTime le $exposureEnd and signInEventTypes/any(t: t eq 'servicePrincipal')"
$spSignIns = Get-MgAuditLogSignIn -Filter $filter -Top 100 -ErrorAction SilentlyContinue
# Check for sign-ins with unusual risk levels
$riskFilter = "createdDateTime ge $exposureStart and createdDateTime le $exposureEnd and riskLevelDuringSignIn eq 'high'"
$riskySignIns = Get-MgAuditLogSignIn -Filter $riskFilter -Top 100 -ErrorAction SilentlyContinue
# Check for unusual directory role assignments during the window
$auditFilter = "activityDateTime ge $exposureStart and activityDateTime le $exposureEnd and category eq 'RoleManagement'"
$roleChanges = Get-MgAuditLogDirectoryAudit -Filter $auditFilter -Top 100 -ErrorAction SilentlyContinue
$anomalyCount = 0
$findings = @()
if ($riskySignIns -and $riskySignIns.Count -gt $anomalyThreshold) {
$anomalyCount += $riskySignIns.Count
$findings += "High-risk sign-ins during exposure window: $($riskySignIns.Count)"
}
if ($roleChanges -and $roleChanges.Count -gt 0) {
$anomalyCount += $roleChanges.Count
$findings += "Privileged role changes during exposure window: $($roleChanges.Count)"
}
Write-Host ''
Write-Host '=== CVE-2026-69836 Exposure Window Audit ===' -ForegroundColor White
Write-Host "Tenant: $TenantId"
Write-Host "Window: $exposureStart to $exposureEnd"
Write-Host "Risky sign-ins: $($riskySignIns.Count)"
Write-Host "Role changes: $($roleChanges.Count)"
Write-Host ''
if ($anomalyCount -gt 0) {
Write-Host 'VULNERABLE - Anomalous activity detected during exposure window. Investigate further.' -ForegroundColor Red
foreach ($f in $findings) { Write-Host " [!] $f" -ForegroundColor Red }
Write-Host ''
Write-Host 'Recommended: Engage your IR team to review these events in detail.' -ForegroundColor Yellow
Disconnect-MgGraph | Out-Null
exit 1
} else {
Write-Host 'PATCHED - No anomalous activity detected during the exposure window.' -ForegroundColor Green
Write-Host 'Microsoft remediated this vulnerability server-side before disclosure.' -ForegroundColor Green
Write-Host 'No customer-side patching action is required.' -ForegroundColor Green
Disconnect-MgGraph | Out-Null
exit 0
}
} catch {
Write-Host "UNKNOWN - Failed to query audit logs: $_" -ForegroundColor Yellow
Write-Host 'Ensure your account has AuditLog.Read.All and Directory.Read.All permissions.' -ForegroundColor Yellow
try { Disconnect-MgGraph | Out-Null } catch {}
exit 2
}