CVE-2026-109469: Entra Device Registration Bypass
Critical CVSS (10.0) reachable over network.
TL;DR - CVE-2026-109469 is a reported CVSS 10.0 authorization bypass involving a user-controlled key in Microsoft Entra Device Registration. - Affected version ranges and the fixed version are not available in the retrieved records; consult Microsoft MSRC directly. - No public proof of concept or confirmed exploitation was identified, but the severity warrants urgent review and remediation.
Summary
CVE-2026-109469 is an authorization-bypass vulnerability in Microsoft Entra Device Registration. The available vulnerability description states that a user-controlled key can allow an unauthorized attacker to elevate privileges over a network. That points to a failure in authorization enforcement around key material used by the device-registration workflow.
The NVD record reports a CVSS base score of 10.0, but the retrieved record does not include the CVSS vector string. It also does not expose affected version ranges, build numbers, an update identifier, or a fixed version. Administrators therefore cannot safely infer a product build boundary or determine patch compliance from the available record alone.
For background, see our software vulnerability glossary and MITRE ATT&CK glossary.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-109469 |
| Product/component | Microsoft Entra Device Registration |
| CVSS base score | 10.0 |
| CVSS vector | Not provided in the retrieved NVD record |
| Attack vector | Network, according to the vulnerability description |
| Authentication | Not explicitly provided; description characterizes the attacker as unauthorized |
| Privileges required | Not explicitly provided; privilege elevation is the stated impact |
| Patch available | Vendor guidance exists through MSRC, but the fixed version or update package was not available in the retrieved data |
| CISA KEV status | Not listed at the time of the referenced lookup |
| Public PoC | None identified in the retrieved references |
The primary source is Microsoft’s MSRC advisory for CVE-2026-109469. Because the advisory is dynamically rendered, the retrieved HTML exposed the application shell rather than the underlying vulnerability metadata. Use the MSRC page as the authority for applicability and remediation decisions.
Root Cause
The stated root cause is an authorization bypass through a user-controlled key. In practical terms, a security decision appears to rely on key material or key-related input that an attacker can influence. If the registration service accepts that input as evidence of identity, ownership, device trust, or authorization without adequately binding it to the expected principal and context, an unauthorized network attacker may be able to obtain privileges they should not possess.
The available data does not identify the vulnerable endpoint, protocol, cryptographic operation, token format, or validation failure. It would be unsafe to assert whether the defect involves key substitution, insufficient proof-of-possession validation, incorrect key-to-device binding, replay handling, or another authorization flaw. Defenders should avoid building detections around a presumed exploit path until Microsoft publishes technical indicators.
The record describes privilege elevation rather than simple information disclosure or denial of service. Identity and device state should therefore drive triage. Investigators should look for unexpected device registrations, changes in device ownership or trust state, unusual privilege assignments, and sign-ins or administrative actions associated with recently registered or modified devices.
Analyst’s Take: The CVSS 10.0 score warrants immediate review, but the missing vector and version data limit precise prioritization. Start with Microsoft’s advisory and the organization’s Entra Device Registration inventory, then use registration and privilege-change logs to identify potentially affected activity.
Who’s Exposed
The identified affected component is Microsoft Entra Device Registration. The retrieved NVD data does not provide a product edition, cloud service boundary, tenant configuration requirement, affected release range, build number, or minimum fixed version. It is therefore not possible to responsibly state that a particular Windows release, Entra Connect version, agent version, or tenant tier is affected.
Organizations should assume potential exposure for triage if they use Microsoft Entra Device Registration or depend on its registration workflow for device identity and access decisions. This is a risk-based assumption, not a confirmed product-version mapping. Environments that do not use the affected component may not be exposed, but that conclusion should be validated against Microsoft’s advisory and the organization’s identity architecture.
| Exposure question | Current answer |
|---|---|
| Specific affected product | Microsoft Entra Device Registration |
| Affected version range | Not published in the retrieved record |
| Fixed version | Not published in the retrieved record |
| Edition or tenant applicability | Not published in the retrieved record |
| Cloud-only or hybrid applicability | Not determined from available data |
| Required deployment condition | Use of the affected device-registration functionality is the reasonable initial scoping assumption |
Do not invent a version boundary from the publication date or from unrelated Microsoft product release numbers. Retrieve the current MSRC advisory, record its affected and fixed versions, then compare those values with the organization’s inventory and tenant configuration.
Severity Breakdown
Microsoft or the NVD record reports a CVSS base score of 10.0. That is the highest possible CVSS base score and signals potentially severe consequences with low attacker friction. The description specifically identifies network exploitation and privilege elevation, which increases the urgency of investigation and remediation.
The retrieved NVD response does not include the vector string. Without it, the individual CVSS components cannot be independently verified. The available material does not establish the exact values for attack complexity, privileges required, user interaction, scope, confidentiality impact, integrity impact, or availability impact.
| CVSS component | Available information |
|---|---|
| Base score | 10.0 |
| Attack vector | Network is stated in the description |
| Attack complexity | Unknown |
| Privileges required | Unknown; attacker is described as unauthorized |
| User interaction | Unknown |
| Scope | Unknown |
| Confidentiality impact | Unknown |
| Integrity impact | Unknown |
| Availability impact | Unknown |
| Vector string | Not provided in the retrieved NVD record |
The absence of a vector should not be interpreted as lower risk. It limits precision when prioritizing affected assets. Until the vendor supplies complete scoring details, prioritize internet-reachable or broadly accessible identity infrastructure, high-value tenants, privileged device-registration workflows, and environments where device identity gates administrative access.
Exploitation Status
CVE-2026-109469 was not identified in the CISA Known Exploited Vulnerabilities catalog during the referenced lookup. No CISA due date, required action, ransomware-campaign flag, or date-added value was returned. Based on that check, there is no CISA confirmation of active exploitation in the wild.
No public proof-of-concept URL was present in the retrieved NVD reference list. The NVD result contained the Microsoft MSRC advisory as its reference, and no additional public exploit reference was identified. There is also no confirmed in-the-wild exploitation evidence in the supplied NVD or CISA lookup results.
These statements are time-bounded. Absence from KEV and absence of a public PoC do not prove that exploitation is impossible or that no private exploit exists. Given the reported 10.0 score, organizations should not wait for KEV inclusion or public exploit publication before reviewing exposure and preparing remediation.
Sources
-
Microsoft Security Response Center: CVE-2026-109469
Authoritative vendor advisory and remediation source. The page should be consulted directly for affected versions, fixed versions, update identifiers, workarounds, and any technical indicators. -
National Vulnerability Database
The retrieved record identifies CVE-2026-109469, Microsoft Entra Device Registration, the authorization-bypass description, and a reported CVSS score of 10.0. The retrieved record did not include the CVSS vector, affected version ranges, fixed version, or a public PoC reference. -
CISA Known Exploited Vulnerabilities Catalog
The referenced lookup did not identify CVE-2026-109469 in the catalog. This means there was no CISA KEV confirmation in the supplied lookup, not that exploitation is impossible or absent from private reporting.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Detection should focus on abnormal Entra device-registration activity and downstream privilege changes. The vulnerable request path, endpoint, and exploit markers are not disclosed, so network signatures for the exploit itself cannot be created reliably from the available information. Security teams should instead correlate device-registration events with identity, directory, conditional-access, and administrative audit data.
Prioritize events involving new or unexpectedly modified devices, changes in device ownership or trust state, registrations from unusual network locations, and subsequent privileged activity. Compare registration timestamps with sign-in records and directory changes. A device that appears immediately before a new role assignment, policy modification, or access to sensitive resources deserves investigation.
Technical Notes
Use your SIEM’s normalized schema where available. The following Kusto-style query is a starting point for environments exporting Entra audit and sign-in data; field names may require adjustment to match the tenant’s schema:
AuditLogs
| where TimeGenerated > ago(30d)
| where Category =~ "Device"
or OperationName has_any ("Register device", "Add device", "Update device", "Device registration")
| project TimeGenerated,
OperationName,
Result,
InitiatedBy,
TargetResources,
AdditionalDetails,
CorrelationId
| order by TimeGenerated desc
Correlate device activity with privileged directory changes rather than treating every registration as malicious:
let registrations =
AuditLogs
| where TimeGenerated > ago(30d)
| where Category =~ "Device"
or OperationName has_any ("Register device", "Add device", "Update device")
| project RegistrationTime=TimeGenerated,
DeviceOperation=OperationName,
RegistrationActor=InitiatedBy,
TargetResources,
CorrelationId;
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has_any (
"Add member to role",
"Add eligible member to role",
"Update device",
"Update directory setting"
)
| join kind=inner registrations on $left.CorrelationId == $right.CorrelationId
| project TimeGenerated, OperationName, InitiatedBy,
RegistrationTime, DeviceOperation, TargetResources, CorrelationId
Where raw audit logs are available, search for device-registration operations, actor identity changes, failed and successful registration attempts, and requests that originate from unexpected autonomous systems or geographies. Preserve the full event payload, correlation identifier, source IP, user agent, device identifier, and target resource. These fields may be essential if Microsoft later publishes exploit-specific indicators.
Remediation Steps
The authoritative remediation source is the Microsoft MSRC advisory for CVE-2026-109469. The retrieved records do not provide an affected version range or fixed version number, so no specific upgrade target can be stated without risking a false remediation claim. Administrators should retrieve the current advisory directly and document the exact affected and fixed versions before closing the vulnerability.
Until the fixed version is confirmed, identify all tenants, services, agents, or management components that use Entra Device Registration. Review device-registration permissions and administrative role assignments, and remove unnecessary registration or device-management privileges. These measures reduce exposure but do not replace the vendor fix.
Technical Notes
After confirming the Microsoft-provided package, update, or component version, use the organization’s approved Microsoft servicing workflow. For Windows-managed systems, a typical verification and update process may include:
# Inventory installed Microsoft updates; do not assume a KB from this CVE record.
Get-HotFix |
Sort-Object InstalledOn -Descending |
Select-Object -First 25 HotFixID, Description, InstalledOn
# After Microsoft publishes the applicable package, install it using the
# organization's approved Windows Update, Intune, Configuration Manager,
# or enterprise software-distribution process.
Do not substitute an arbitrary KB number or build number. The correct command depends on the component and servicing model identified by Microsoft. Once the advisory specifies the update, record the exact package or build and verify deployment across all affected systems or tenant configurations.
If Microsoft documents a temporary workaround, apply that workaround exactly as described in the MSRC advisory. Without a published workaround, practical interim controls include restricting device-registration administration to tightly controlled identities, reviewing conditional-access policies for device trust assumptions, monitoring registration and privilege changes, and disabling nonessential registration paths only after validating business impact. These controls may reduce risk but cannot correct the authorization flaw.
After remediation, validate both the installed or reported fixed version and the service behavior. Recheck device-registration audit events, confirm that privileged workflows remain functional, and review historical logs for suspicious registrations or privilege changes during the exposure window. If unauthorized elevation is suspected, revoke affected sessions and credentials according to the organization’s incident-response procedures, investigate the associated devices and identities, and preserve relevant audit data.