← Back to Feed CACHED · 2026-11-07 11:48:38 · CACHE_KEY CVE-2026-109469
CVE-2026-109469 · CWE-639 · Disclosed 2026-11-06

Microsoft Entra Device Registration authorization bypass via user-controlled key

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

Microsoft already changed the locks on the apartment building while tenants were asleep

CVE-2026-109469 is an authorization bypass through user-controlled key in Microsoft Entra Device Registration, the cloud service that registers devices into Entra ID. An unauthenticated network attacker could tamper with a device registration key to obtain an unauthorized device identity and elevate privileges over the network. There is no customer-installed version; the vulnerable component was the Microsoft-operated service used by essentially every Entra ID tenant before the fix.

Microsoft assigned a CVSS 10.0 because the theoretical pre-fix chain is network-based, low-complexity, with no privileges and changed scope. That intrinsic score does not reflect the current defender reality: Microsoft completed service-side remediation by 5 November 2026, there is no customer patch or configuration to apply, and no exploitation or public proof of concept has surfaced. For an enterprise patching team, this is a cloud-service incident the vendor has already closed.

"Microsoft already fixed the service side of Entra Device Registration; no customer patch, no known exploit, treat as backlog hygiene at most."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain target tenant ID and discover Entra device registration endpoint

An attacker only needs network egress to Microsoft's public Entra ID endpoints and the target tenant identifier. Tenant IDs are often available in public metadata, login pages, or leaked config. The vulnerable endpoint is the standard cloud device registration API, not a customer-hosted service.
Conditions required:
  • Network access to Microsoft Entra ID endpoints
  • Target tenant ID
Where this breaks in practice:
  • No customer-controlled exposure; cannot be blocked without breaking legitimate authentication
  • Tenant ID alone is not enough; the attacker must know how to trigger the authorization bypass
Detection/coverage: None from customer perimeter; Microsoft service telemetry may have identified exploit attempts pre-remediation.
STEP 02

Submit a crafted device registration request with a user-controlled key

The attacker sends a registration or update request where the key field — likely a device ID or registration secret — is chosen to collide with a victim tenant's existing device object. Due to CWE-639, the service trusts this key to locate the device without proving ownership.
Conditions required:
  • Knowledge of a valid device key format or a benign device ID
  • Reachable registration API
Where this breaks in practice:
  • Microsoft has already patched the service-side authorization check
  • No public request payload or reproducer exists to guide exploitation
Detection/coverage: Microsoft service logs / abuse telemetry; customer-side Entra audit logs may show anomalous device registration attempts from unexpected IPs.
STEP 03

Receive or reuse a valid device identity in the target tenant

If the bypass succeeds, the service returns a device credential or marks the attacker's device as registered to the target tenant. That device identity can then participate in Entra ID device-based policies and certificate-based authentication.
Conditions required:
  • Successful authorization bypass
  • Target tenant permits device registration or has hybrid join configured
Where this breaks in practice:
  • Service-side fix prevents this step
  • Modern tenants may require additional registration restrictions or MFA, but CVE vector says no user interaction
Detection/coverage: Entra ID audit logs: Add device events with missing/unexpected initiator; Microsoft 365 Defender abnormal device registration alerts.
STEP 04

Authenticate to Entra ID integrated resources as the unauthorized device

With the device identity, the attacker can request tokens for APIs, web apps, or on-premises resources via hybrid join trust. The impact can include reading or modifying data, depending on the device's Azure AD role and assigned permissions.
Conditions required:
  • Device object exists in tenant
  • Resource allows device-based auth or PRT
Where this breaks in practice:
  • Requires the prior bypass to succeed, which is no longer true post-remediation
  • Device-only credentials typically have limited roles unless combined with other misconfigurations
Detection/coverage: Sign-in logs showing device logon from unexpected IPs; risky sign-in and impossible travel detections.
STEP 05

Elevate from device identity to broader tenant access

In a worst-case scenario before the fix, the attacker might manipulate device compliance or conditional access to gain additional privileges. Because Entra Device Registration is part of the identity plane, the potential blast radius was tenant-scale.
Conditions required:
  • Prior bypass completed and device identity accepted
  • Victim tenant has valuable roles bound to device identity or weak conditional access
Where this breaks in practice:
  • Microsoft remediated the cloud service; no customer-side residual vulnerability remains
  • No evidence attackers ever achieved this path in the wild
Detection/coverage: Entra ID audit logs, Microsoft Defender XDR incident correlation, and Microsoft service-side telemetry.
03 · Compensating Control

1
IGNORE 0.0→IGNORE 0.0
Document the CVE and close it in your risk register — Because Microsoft has already remediated the service-side flaw, there is no customer mitigation to deploy. Record the advisory, note that Entra Device Registration is a cloud service with no on-premises patch, and set a 90-day review only if you have evidence of unusual device registration patterns.
2
IGNORE 0.0→LOW 2.0
Review Entra ID audit logs for anomalous device registration events — As a one-time hygiene check, query Add device events from the last 30 days and look for initiator identities that are missing, unknown, or originate from unexpected geographies. This does not change the patch status but can uncover prior abuse.
What doesn't work
  • Blocking outbound access to Microsoft Entra ID endpoints at the firewall — breaks legitimate authentication and cannot isolate a Microsoft-hosted service.
  • Deploying a Windows or Microsoft Entra Connect update — no client-side patch exists; the vulnerability was in Microsoft's cloud service.
  • Conditional Access blocking device registration — can disrupt legitimate enrollments and did not target the vulnerable service-side authorization check.
04 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo exploitation reported; no IOCs or campaigns tied to CVE-2026-109469 as of 2026-11-06.
Proof of conceptNone public; no GitHub repos, nuclei templates, or ExploitDB entries identified.
EPSSNot available from configured EPSS source; too soon after publication for a reliable score/percentile.
KEV statusNot listed in CISA KEV; no active exploitation evidence.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — network, no privileges, changed scope, high C/I/A.
Affected versionsMicrosoft Entra Device Registration cloud service, all tenants before service-side fix; no customer-installed version.
Fixed versionsService-side remediation completed by Microsoft; no customer patch, update, or version to deploy.
Scanning/exposureNot applicable to external scanners; component is Microsoft-hosted and not part of customer internet attack surface.
Disclosure date2026-11-05 in Microsoft Security Update Guide; CVE published 2026-11-06.
Reporting sourceMicrosoft Corporation CNA; no independent researcher credited in available records.

Sources.

  1. NVD
  2. Brandefense
  3. OpenCVE
  4. Rapid7
  5. CIRCL
  6. Mallory
05 · The Call

Final Verdict
↓ DOWNGRADED to IGNORE (0.0/10)

Why this verdict

  • Service-side fix already shipped: Microsoft reports the vulnerability was remediated on its own infrastructure; there is no customer-installed component, no patch to schedule, and no configuration to change.
  • No known exploitation or PoC: CISA KEV does not list it, EPSS is not available, and no public exploit code, nuclei templates, or IOCs have appeared.
  • Role multiplier: Entra Device Registration sits in the Entra ID identity plane, so if the chain were still live the impact would be tenant-scale; however the service-side fix means the documented chain can no longer succeed, so the high-value-role floor does not force a HIGH/CRITICAL verdict for defenders.

Why not higher?

Not CRITICAL/HIGH because the vulnerability was a Microsoft-operated cloud service bug that has already been remediated service-side. There is no customer deployment to test, patch, or expose; no KEV listing or active exploitation; and no public PoC. Assigning a high severity would create phantom work for patching teams.

Why not lower?

IGNORE is the lowest action tier and already carries a 0.0 score; there is no lower severity to assign. We retain only a documentation action because the advisory should be recorded in the risk register, not because residual exploitability remains.

06 · Verification

Crowdsourced verification payload.

Run this on a Microsoft 365/Entra ID administrator workstation with the Microsoft Graph PowerShell module installed. First authenticate with Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All', then execute pwsh -File check-cve-2026-109469.ps1 -DaysBack 30. The script reviews Entra ID directory audit logs for Add device events with missing initiator identity and exits 0 for PATCHED/no-anomaly, 1 for VULNERABLE-suspect, or 3 for UNKNOWN.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#requires -Modules Microsoft.Graph.Authentication
[CmdletBinding()]
param(
    [int]$DaysBack = 30
)
$ErrorActionPreference = 'Stop'

function Test-GraphModule {
    if (-not (Get-Module -ListAvailable -Name Microsoft.Graph.Authentication)) {
        Write-Host 'UNKNOWN - Microsoft.Graph.Authentication module not installed'
        exit 3
    }
}

function Connect-Check {
    $ctx = Get-MgContext
    if (-not $ctx) {
        Write-Host 'UNKNOWN - Not connected to Microsoft Graph. Run Connect-MgGraph -Scopes ''AuditLog.Read.All'',''Directory.Read.All'' first.'
        exit 3
    }
}

function Inspect-DeviceRegistrationLogs {
    $since = (Get-Date).AddDays(-$DaysBack).ToUniversalTime()
    $filter = "activityDateTime ge $($since.ToString('yyyy-MM-ddTHH:mm:ssZ')) and activityDisplayName eq 'Add device'"
    try {
        $logs = Get-MgAuditLogDirectoryAudit -Filter $filter -All -ErrorAction Stop
    } catch {
        Write-Host "UNKNOWN - Failed to query Entra audit logs: $($_.Exception.Message)"
        exit 3
    }
    if ($null -eq $logs -or $logs.Count -eq 0) {
        Write-Host 'PATCHED - No Add device events in last' $DaysBack 'days'
        exit 0
    }
    $suspicious = @($logs | Where-Object {
        $_.InitiatedBy -and -not $_.InitiatedBy.User -and -not $_.InitiatedBy.App
    })
    if ($suspicious.Count -gt 0) {
        Write-Host 'VULNERABLE - Suspicious device registration events with missing initiator found; review these IDs:'
        $suspicious | Select-Object Id, ActivityDateTime, TargetResources | Format-List
        exit 1
    } else {
        Write-Host 'PATCHED - Device registration events found, none with missing initiator identity'
        exit 0
    }
}

Test-GraphModule
Connect-Check
Inspect-DeviceRegistrationLogs