← Back to Feed CACHED · 2026-10-08 01:22:27 · CACHE_KEY CVE-2026-69836
CVE-2026-69836 · CWE-502 · Disclosed 2026-08-20

Microsoft Entra ID Unauthenticated Remote Code Execution via Deserialization of Untrusted Data

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Cloud-only vuln already fixed server-side. Nothing to patch on your hosts."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify the vulnerable deserialization endpoint

The attacker would need to discover the specific Entra ID service endpoint accepting serialized data without authentication. Microsoft has not disclosed this endpoint publicly. Because Entra ID is a multi-tenant cloud service, the attack surface sits behind Microsoft's own network perimeter, load balancers, and WAF infrastructure — not behind yours.
Conditions required:
  • Knowledge of the undisclosed vulnerable endpoint in Microsoft's Entra ID infrastructure
  • Network reachability to that endpoint (public internet to Microsoft's cloud edge)
Where this breaks in practice:
  • 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
STEP 02

Craft a malicious serialized payload

The attacker constructs a serialized object exploiting a gadget chain available in the Entra ID service's runtime. Without knowledge of the target framework, libraries, and deserialization mechanism, this step requires significant reverse-engineering of a cloud service the attacker cannot inspect. No public PoC with a working payload exists.
Conditions required:
  • 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)
Where this breaks in practice:
  • 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)
STEP 03

Submit payload and achieve RCE in Microsoft's infrastructure

The attacker sends the crafted payload to the vulnerable endpoint. If deserialization succeeds, arbitrary code executes within Microsoft's Entra ID service context — inside Microsoft's tenant, not yours. The blast radius is Microsoft's cloud control plane, not your on-premises or IaaS hosts.
Conditions required:
  • Steps 1 and 2 succeed
  • The endpoint has not yet been patched by Microsoft
Where this breaks in practice:
  • 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
STEP 04

Pivot from Entra ID service internals to tenant data

Post-exploitation, the attacker would need to leverage their foothold inside Microsoft's Entra ID service to access tenant-specific data — tokens, credentials, directory objects. This would require navigating Microsoft's internal service isolation, tenant boundaries, and data-plane segmentation. No evidence suggests this was achieved or even attempted.
Conditions required:
  • Successful RCE in Microsoft's infrastructure (Step 3)
  • Ability to bypass Microsoft's internal tenant isolation and service segmentation
Where this breaks in practice:
  • 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
Detection/coverage: Microsoft's internal telemetry; no customer-side detection possible for this step
03 · Compensating Control

1
IGNORE 0.0→IGNORE 0.0
Audit Entra ID sign-in logs for the pre-disclosure exposure window — Although Microsoft states no exploitation occurred, a prudent security team performs independent verification. Query the Entra ID sign-in logs and audit logs for anomalous activity between July 1 and August 20, 2026 — the plausible exposure window. Look for unusual service principal authentications, unexpected token issuance, or sign-ins from anomalous geolocations. This is a one-time forensic exercise, not an ongoing control. Complete within 30 days as a best practice (no noisgate mitigation SLA applies for IGNORE-rated findings).
2
IGNORE 0.0→IGNORE 0.0
Verify conditional access policies and federation trusts are intact — If an attacker had compromised Entra ID's control plane during the exposure window, they could theoretically have modified tenant configurations. Verify that your conditional access policies, federation trust relationships (SAML/WS-Fed), custom domains, and privileged role assignments match your documented baselines. Again, this is a one-time verification exercise.
3
IGNORE 0.0→IGNORE 0.0
Document the provider-remediated vulnerability for compliance — Create an explicit record in your vulnerability management system categorized as "provider-remediated / no customer action." Reference Microsoft's advisory stating full mitigation with no customer action required. This satisfies audit requirements under frameworks like SOC 2, ISO 27001, NIS2, and DORA without inflating your open-vulnerability count. Link to the vendor attestation and your log-review results.
4
IGNORE 0.0→IGNORE 0.0
Flag this CVE as a governance-gap test case for your VM program — Use CVE-2026-69836 as a catalyst to update your vulnerability management policy with an explicit "provider-remediated" category. Ensure your SLA language handles cloud-service CVEs that require no customer remediation. This prevents future CVSS 10.0 cloud disclosures from generating false-positive fire drills.
What doesn't work
  • 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.com or login.microsoft.com would 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.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone 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 StatusNot 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 AvailabilityNo 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 Score0.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 VectorCVSS: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 VersionsAll 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 VersionsServer-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 DataNot 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.
DiscovererRobert Fitzpatrick, Microsoft Principal Security Engineer (internal discovery). No external researcher credit.
Disclosure ModelMicrosoft'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.

  1. The Hacker News — Microsoft Entra ID Flaw CVSS 10.0
  2. Cybersecurity Dive — Microsoft discloses maximum severity flaw in Entra ID
  3. Help Net Security — Microsoft patches critical Entra ID vulnerability
  4. ComplianceHub — CVSS 10.0 You Cannot Patch: Governance Gap in Provider-Remediated Vulnerabilities
  5. Halfteck — Microsoft rated its own Entra ID bug 'exploited,' then walked it back
  6. Start With Identity — Microsoft Entra ID CVSS 10 Deserialization Flaw
  7. GitHub Advisory Database — GHSA-v6wh-624g-vvmv
  8. Windows Forum — CVE-2026-69836 Entra ID Flaw Was Not Exploited
05 · The Call

Final Verdict
↓ DOWNGRADED to IGNORE (0.0/10)

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.

06 · Verification

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.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#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
}