CVE-2026-45658

What it actually does

This vulnerability is a BitLocker security feature bypass in affected Windows client and server releases. An attacker with local/physical access and the required local interaction can defeat a protection mechanism intended to preserve the confidentiality and integrity of BitLocker-protected data. Successful exploitation can expose encrypted volume contents and may allow offline tampering with the operating system or data that BitLocker is expected to protect. This is not a remote network vulnerability; the primary exposure is devices that can be physically accessed, stolen, lost, serviced by untrusted parties, or booted with attacker-controlled media or hardware.

Why it matters to the business

The main business risk is that a lost, stolen, or physically accessed Windows device may no longer be protected by BitLocker as expected, potentially leading to disclosure of sensitive files, credential material, regulated data, or offline modification of systems. This is most important for laptops, executive/user workstations, branch-office servers, kiosks, and other systems deployed outside tightly controlled facilities. The issue has high potential impact if exploited, but current available signals indicate low broad exploitation likelihood: EPSS is low, it is not listed in CISA KEV, it is not marked as ransomware-used, and no mature public exploitation is indicated in the provided data.

How an attack unfolds

An attacker first obtains physical access to an affected Windows system, such as through theft, temporary possession, malicious servicing, or access to an unattended device. The attacker then uses the BitLocker protection mechanism failure to bypass a security boundary that should prevent access to protected data. If successful, the attacker can access data from the encrypted volume or alter files offline before returning or reusing the device. The attack does not require a victim to click a link or expose a network service, but it does depend on physical/local access conditions and an affected Windows version. Because the activity may happen while the device is offline or outside normal monitoring, successful exploitation may leave few conventional network indicators.

How to fix it

Apply the Microsoft security update that addresses this BitLocker bypass for all affected Windows versions, including Windows 10 1607/1809/21H2/22H2, Windows 11 23H2/24H2/25H2/26H1, Windows Server 2012/2016/2019/2022/2025, as applicable. No exact fixed build numbers were provided in the input, so use Microsoft Security Update Guide, Windows Update, WSUS, Microsoft Intune, Configuration Manager, or the relevant offline servicing channel to verify the specific cumulative update for each OS release. For unsupported or extended-support operating systems, ensure Extended Security Updates are available or prioritize OS upgrade/replacement. As compensating controls, enforce TPM-backed BitLocker with Secure Boot where supported, require pre-boot authentication for high-risk devices where operationally feasible, prevent boot from external media, lock UEFI/BIOS configuration with an administrator password, enable device encryption compliance monitoring, restrict physical access, and rotate/recover BitLocker recovery keys after suspected exposure.

How to confirm the fix worked

Confirm that each affected Windows asset has installed the Microsoft cumulative/security update that includes the fix for this vulnerability. Validate through Windows Update history, installed KB inventory, vulnerability scanner results, endpoint management compliance reports, or Microsoft Security Update Guide mapping for the OS build. Confirm BitLocker remains enabled and protection is active using approved endpoint management tooling or commands such as manage-bde -status and PowerShell BitLocker status checks. Verify Secure Boot, TPM readiness, and firmware boot-order controls are enabled for devices where those controls are required. For lost, stolen, or physically accessed devices, treat patch validation alone as insufficient: review BitLocker recovery-key access, rotate recovery material if needed, and consider credential resets or device reimaging if compromise cannot be ruled out.

Typical attack path

1. Identify or obtain physical access to an affected Windows 10, Windows 11, or Windows Server device protected by BitLocker.
2. Interact locally with the device or its boot/storage environment under conditions that trigger the BitLocker protection bypass.
3. Bypass the intended BitLocker security control that should prevent unauthorized access to the protected volume.
4. Read sensitive files, extract credential material, or copy data from the volume.
5. Optionally modify offline system files, boot configuration, or data before returning, discarding, or further abusing the device.

How to detect it

Detection should focus on evidence of physical access, BitLocker state changes, recovery-key usage, boot or firmware configuration changes, and post-access credential or data abuse. Review Windows Event Logs including Microsoft-Windows-BitLocker/BitLocker Management, Microsoft-Windows-BitLocker-API/Management, System, Security, Microsoft-Windows-TPM-WMI, Microsoft-Windows-Kernel-Boot, and Microsoft-Windows-CodeIntegrity/Operational where available. Look for BitLocker being suspended, disabled, reconfigured, or entering recovery unexpectedly; unexpected access to escrowed recovery keys in directory, MDM, or cloud management audit logs; boot configuration edits; firmware/secure boot changes; and unusual logons shortly after a device was missing, transported, repaired, or physically accessed. Because exploitation may occur offline, absence of logs does not prove absence of compromise. Treat sudden gaps in endpoint telemetry, unexpected reboot sequences, recovery prompts, or changes to BitLocker protectors as investigation triggers. There are no reliable network IOCs for this vulnerability based on the provided data.

• Microsoft-Windows-BitLocker/BitLocker Management
• Microsoft-Windows-BitLocker-API/Management
• Microsoft-Windows-TPM-WMI
• Microsoft-Windows-Kernel-Boot
• Microsoft-Windows-CodeIntegrity/Operational
• manage-bde -protectors -disable
• manage-bde -protectors -delete
• manage-bde -off
• manage-bde -pause
• Suspend-BitLocker
• Disable-BitLocker
• Remove-BitLockerKeyProtector
• bcdedit /set
• bcdedit /deletevalue
• reagentc /disable
• BitLocker protection is suspended
• BitLocker Drive Encryption recovery key
• BitLocker recovery
• Secure Boot state
• TPM-WMI

What your security team should do

• Prioritize patching mobile endpoints, executive systems, administrator workstations, kiosks, branch-office systems, and any servers or workstations that may be physically accessible to untrusted users.
• Inventory affected Windows 10, Windows 11, and Windows Server versions and map each to the applicable Microsoft cumulative update or servicing baseline.
• Ensure BitLocker is enabled, protection is not suspended, recovery keys are escrowed securely, and Secure Boot/TPM protections are enforced according to device risk.
• Harden physical-attack resistance by disabling external boot, locking UEFI/BIOS settings, requiring firmware passwords, and limiting physical access to servers and shared devices.
• For high-risk fleets, evaluate pre-boot PIN or other stronger BitLocker protector configurations, balancing usability and recovery operations.
• Create detection content for BitLocker suspension/disablement, boot configuration changes, unexpected recovery-key access, and endpoint evidence of offline tampering.
• If a device was lost, stolen, serviced by an untrusted party, or physically accessible before patching, perform incident triage rather than assuming encryption protected the data.
• Monitor Microsoft advisories for fixed build guidance and any change in exploitation status, especially because the issue is 63 days past publication even though current EPSS and KEV signals are low.