CVE-2026-45655

What it actually does

This vulnerability is a protection mechanism failure in Windows BitLocker that can allow an unauthenticated attacker with physical access to a device to bypass expected BitLocker security protections and access protected data. The CVSS vector indicates physical attack requirements, low attack complexity, no privileges, no user interaction, changed scope, and high confidentiality impact, with no direct integrity or availability impact. The core risk is exposure of data that organizations expect to remain encrypted or inaccessible when a device is lost, stolen, intercepted, or otherwise physically accessible to an attacker.

Why it matters to the business

The primary business consequence is loss of confidentiality for data stored on affected Windows workstations and servers, especially laptops, field devices, kiosks, branch-office systems, and any server or endpoint that could be physically accessed. A successful attack could expose regulated data, credentials, intellectual property, cached emails, documents, browser data, VPN materials, or other sensitive local files despite BitLocker being enabled. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but physical-access flaws remain important for organizations with lost-device risk, high-value endpoints, shared facilities, travel-heavy users, or adversaries capable of device theft or interdiction.

How an attack unfolds

An attacker must obtain physical access to an affected Windows device, such as through theft, temporary access, supply-chain interception, or access to an unattended system. The attacker then attempts to manipulate the boot, recovery, hardware, or platform-protection path in a way that causes BitLocker’s intended protection mechanism to fail. If successful, the attacker bypasses the security feature that should prevent access to encrypted local data and can read sensitive contents without needing Windows credentials or prior privileges. Because this is a physical attack path and exploit maturity is currently reported as none, exploitation is more likely to be targeted than opportunistic internet-scale activity, but successful exploitation can be highly consequential for confidentiality.

How to fix it

Apply the relevant Microsoft security updates for all affected Windows versions as soon as they are available through Windows Update, Microsoft Update Catalog, WSUS, Microsoft Configuration Manager, Intune, or the organization’s standard patch-management process. Because no exact fixed build numbers were provided, validate remediation against Microsoft’s official advisory and monthly cumulative update guidance for Windows 10, Windows 11, Windows Server 2012, Windows Server 2016, Windows Server 2019, Windows Server 2022, and Windows Server 2025. Prioritize portable endpoints, executive and administrator devices, devices used for regulated data, shared-location systems, branch systems, kiosks, and any device with elevated physical-access risk. As mitigations, enforce TPM plus PIN or equivalent pre-boot authentication for high-risk systems where operationally feasible, ensure Secure Boot is enabled, restrict boot from external media, lock firmware/UEFI settings with an administrator password, disable unused external boot paths, escrow and rotate recovery keys according to policy, and maintain strict lost/stolen-device response procedures.

How to confirm the fix worked

Confirm affected systems have received the Microsoft cumulative update or security update that addresses this vulnerability for their Windows release. Validate that BitLocker remains enabled and protecting all intended volumes after patching, that protection is not suspended, and that recovery-key escrow is healthy. On representative devices, verify Secure Boot state, TPM state, configured key protectors, firmware boot order, and whether external boot is disabled or restricted. Use enterprise endpoint-management reporting to identify Windows 10, Windows 11, and Windows Server assets that are missing the relevant update, have BitLocker disabled, have BitLocker protection suspended, or use weaker protector configurations. For high-risk fleets, perform controlled physical-access validation to ensure the device still requires the expected pre-boot authentication or recovery workflow after patching.

Typical attack path

1. Identify or obtain an affected Windows device that uses BitLocker or relies on BitLocker for data-at-rest protection.
2. Gain physical possession of the device or temporary hands-on access without needing valid credentials.
3. Interact with the system boot, recovery, hardware, or platform security flow to trigger the BitLocker protection mechanism failure.
4. Bypass the expected BitLocker security control that should prevent unauthorized access to protected storage.
5. Access or extract local files, cached secrets, user data, system data, or other sensitive information from the device.

How to detect it

There may be no reliable remote telemetry proving exploitation because the attack requires physical access and may occur while the operating system is offline. Investigations should focus on evidence of device theft or unauthorized access, unexpected boot or recovery activity, BitLocker state changes, firmware or boot-order changes, and unusual recovery-key use. Review Windows Event Logs including Microsoft-Windows-BitLocker/BitLocker Management, Microsoft-Windows-BitLocker-API/Management where present, System, Security, Microsoft-Windows-Kernel-Boot, Microsoft-Windows-TPM-WMI, and Microsoft-Windows-SecureBoot. Look for BitLocker protection suspension or disablement, recovery mode events, protector changes, recovery-key backup or retrieval events, boot configuration modifications, Secure Boot state changes, unexpected WinRE or external-boot activity, and device check-ins after reported loss or unexplained downtime. In endpoint-management and identity systems, review BitLocker recovery-key access logs for unusual retrievals, especially by unexpected administrators, at unusual times, or shortly before or after a device was lost, serviced, or physically handled. If a device is recovered after being outside organizational control, perform forensic triage before reconnecting it to trusted networks, including review of boot configuration, BitLocker protector state, firmware settings, last boot times, mounted volume artifacts, and signs of offline data access.

• BitLocker protection is suspended
• BitLocker protection was suspended
• BitLocker protection is off
• BitLocker Drive Encryption: Configuration Tool
• manage-bde -protectors -disable
• manage-bde -protectors -delete
• manage-bde -off
• manage-bde -unlock
• manage-bde -forcerecovery
• bdeunlock.exe
• bdehdcfg.exe
• bcdedit /set
• bcdedit /deletevalue
• reagentc /disable
• reagentc /enable
• Microsoft-Windows-BitLocker/BitLocker Management
• Microsoft-Windows-BitLocker-API/Management
• Microsoft-Windows-Kernel-Boot
• Microsoft-Windows-TPM-WMI
• Microsoft-Windows-SecureBoot
• The BitLocker encryption key cannot be obtained from the Trusted Platform Module
• BitLocker recovery key
• BitLocker recovery password
• A boot application has changed since BitLocker was enabled
• Secure Boot state
• WinRE
• Windows Recovery Environment
• \Windows\System32\manage-bde.exe
• \Windows\System32\bcdedit.exe
• \Windows\System32\reagentc.exe
• \Windows\System32\bdeunlock.exe

What your security team should do

• Prioritize patch deployment to mobile endpoints, high-value administrator workstations, executive devices, shared-location devices, and systems with elevated theft or physical-access risk.
• Use asset inventory to identify affected Windows 10, Windows 11, and Windows Server versions and track patch compliance against Microsoft’s advisory for this vulnerability.
• Audit BitLocker configuration across the fleet for protection status, suspended protection, missing TPM protectors, missing recovery-key escrow, and weak pre-boot configurations.
• For sensitive systems, require TPM plus PIN or another stronger pre-boot authentication model where feasible, and verify Secure Boot and firmware protections are enabled.
• Review lost, stolen, serviced, or temporarily unattended device cases since publication for signs of suspicious boot, recovery, or BitLocker activity.
• Restrict boot from external media and protect UEFI/BIOS configuration with strong administrative controls, especially on portable and field-deployed systems.
• Update incident-response playbooks for lost or stolen BitLocker-protected devices to include credential rotation, recovery-key rotation, and forensic review when a device is recovered.
• Monitor Microsoft guidance for fixed build information, known exploitability updates, and any change in KEV, ransomware, or exploit-maturity status.