CVE-2026-45642

What it actually does

This is an improper input validation flaw affecting Microsoft Azure Attestation and Device Health Attestation workflows on supported Windows client and server platforms. An attacker who is already authorized at a high privilege level and has physical access to the device can manipulate attestation-related inputs so that the service accepts or trusts incorrect device health evidence. The primary impact is integrity: attestation results may falsely indicate that a device is trusted, healthy, or compliant when it is not. The vulnerability does not directly provide remote code execution, data disclosure, or denial of service.

Why it matters to the business

Organizations that rely on device attestation for access control, compliance, zero-trust posture checks, regulated workload access, or hardware-backed trust decisions could make incorrect access decisions. A compromised or tampered device may be treated as healthy, allowing it to access resources that should require a verified trusted state. Broad internet-scale exploitation is less likely because exploitation requires physical access and high privileges, and the CVE is not listed in CISA KEV with low EPSS activity; however, the impact can be meaningful in high-security, shared-device, kiosk, lab, manufacturing, executive, or privileged-administration environments where device trust is a gate to sensitive systems.

How an attack unfolds

An attacker first obtains physical access to an affected Windows device and already has high local privileges or an equivalent authorized position. They then alter or craft attestation-related inputs, measurements, or device health evidence in a way that is not properly rejected by the affected attestation validation logic. The attacker submits the manipulated evidence through the normal Azure Attestation or Device Health Attestation flow. If successful, the service or relying access-control system accepts the spoofed attestation state and issues or honors a result indicating the device is healthy or trustworthy. The attacker can then use that trusted device posture to satisfy conditional access, compliance, or device-trust checks despite the device not actually meeting the expected security state.

How to fix it

Apply the latest Microsoft security updates and cumulative updates for all affected Windows versions, including Windows 10, Windows 11, Windows Server 2012, 2016, 2019, 2022, and 2025 where applicable. Because no discrete fixed version was provided, use the relevant Microsoft security update guidance for CVE-2026-45642 and ensure systems are fully current. Prioritize devices whose attestation state is used for privileged access, conditional access, compliance enforcement, kiosk scenarios, shared workstations, administrative jump systems, or regulated workloads. As defense in depth, restrict physical access, require BitLocker with TPM protection, enable Secure Boot, enforce TPM health requirements, monitor for TPM resets or boot configuration changes, and avoid relying on attestation alone as the only control for highly sensitive access decisions. Re-evaluate or expire cached attestation/compliance states after patching where relying systems support it.

How to confirm the fix worked

Confirm affected systems have installed the applicable Microsoft cumulative security update using enterprise patch reporting, Windows Update history, Microsoft Defender Vulnerability Management, WSUS, Intune, SCCM, or PowerShell such as Get-HotFix where appropriate. Verify that Windows 10, Windows 11, and Windows Server assets listed in scope are no longer missing the relevant security update. Validate that Secure Boot and TPM health are enabled and reporting correctly. Run a controlled device attestation check after patching and confirm relying systems receive expected healthy/unhealthy results. Where possible, test that malformed or inconsistent attestation evidence is rejected. Review conditional access, compliance, or device-trust systems to ensure stale trusted states are refreshed after remediation.

Typical attack path

1. Gain physical access to an affected Windows client or server device.
2. Use already-held high privileges or authorized administrative capability on the device.
3. Modify, replay, or craft attestation-related device health inputs or measurements.
4. Submit the manipulated evidence to Azure Attestation or Device Health Attestation through legitimate attestation workflows.
5. Receive or cause acceptance of a spoofed healthy/trusted attestation result.
6. Use the falsely trusted device posture to bypass device health, compliance, or conditional access controls.

How to detect it

Detection is difficult because successful exploitation uses legitimate attestation workflows and does not necessarily leave a unique exploit artifact. Focus on correlation rather than a single signature. Review Azure Attestation and device health attestation logs for unusual successful attestations, malformed or repeatedly failed attestation requests followed by success, attestation from devices with inconsistent health posture, or sudden compliance transitions from unhealthy to healthy without a normal remediation path. On endpoints, review Windows security, TPM, BitLocker, Secure Boot, Code Integrity, MDM, and device compliance logs for evidence of physical tampering or configuration changes around the time of attestation. Look for local administrative logons, console logons, boot configuration changes, TPM clear/ownership changes, BitLocker recovery events, Secure Boot disabled or re-enabled events, PCR/measurement changes, and unexpected device check-ins after custody gaps. In identity and access logs, look for sensitive access granted immediately after a new or refreshed device-trust result, especially from devices with recent hardware, boot, or compliance anomalies.

• Microsoft-Windows-DeviceHealthAttestation/Operational
• Microsoft-Windows-TPM-WMI/Operational
• Microsoft-Windows-BitLocker/BitLocker Management
• Microsoft-Windows-CodeIntegrity/Operational
• Microsoft-Windows-Kernel-Boot
• Microsoft-Windows-SecureBoot
• TPM clear
• TPM ownership
• Secure Boot disabled
• BitLocker recovery
• DeviceHealthAttestation
• Azure Attestation
• attestation succeeded
• attestation failed
• device compliance changed
• PCR validation
• Boot Configuration Data
• bcdedit.exe

What your security team should do

• Prioritize patching devices whose attestation status is used to grant access to sensitive applications, privileged administration paths, regulated data, or production management systems.
• Review physical security controls for high-value Windows endpoints and servers, especially shared, kiosk, lab, executive, and administrative devices.
• Hunt for suspicious attestation successes that coincide with TPM resets, Secure Boot changes, BitLocker recovery events, unexpected local administrator activity, or physical console access.
• Expire or force refresh of cached device compliance and attestation states after patch deployment where supported.
• Ensure conditional access and zero-trust policies do not depend solely on device attestation; combine attestation with user risk, phishing-resistant authentication, device management state, and endpoint detection signals.
• Monitor Microsoft advisories for any later exploit maturity changes, public proof-of-concept activity, or inclusion in known exploited vulnerability catalogs.