CVE-2026-45656

What it actually does

This is a local Windows UEFI protection-mechanism failure that allows an already authenticated attacker to bypass a security feature in the boot/firmware trust chain. Because UEFI protections execute before the operating system is fully initialized, a successful bypass can undermine assumptions made by Secure Boot, BitLocker, virtualization-based security, credential isolation, kernel integrity, or other platform protections. The vulnerability is local, low-complexity, requires valid access to the system, and does not require user interaction; the assessed impact is high for confidentiality, integrity, and availability because boot-level security bypasses can enable persistent tampering, data exposure, or disabling of critical defenses.

Why it matters to the business

An attacker who already has access to a Windows workstation or server could weaken foundational boot security and potentially gain durable control of the device, making incident response and recovery harder than with ordinary malware. Compromised endpoints may expose sensitive data, credentials, regulated information, or critical business applications. The issue affects many supported Windows client and server versions, including Windows 10, Windows 11, Windows Server 2012 through 2025, so enterprise exposure may be broad. Current public exploitation signals are low: EPSS is 0.00307, it is not listed in CISA KEV, no ransomware use is indicated, and exploit maturity is reported as none; however, the high CVSS impact and boot-chain context justify timely remediation, especially for privileged workstations, domain administration systems, servers, kiosks, and devices that rely on Secure Boot or BitLocker for trust.

How an attack unfolds

An attacker first obtains local authenticated access to an affected Windows system, such as through stolen credentials, malware running in a user context, or interactive access. They then execute tooling or commands that abuse the UEFI protection failure to bypass a security feature that normally protects the boot path. Once the protection is bypassed, the attacker may attempt to modify boot configuration, tamper with EFI System Partition contents, disable or weaken encryption and integrity controls, load unauthorized boot components, or stage persistence that executes before normal endpoint security controls are active. After reboot or policy refresh, the attacker can use the weakened trust state to access protected data, hide malware, interfere with recovery, or escalate post-compromise activity. There is no indication from the provided data that this is being actively exploited at scale, but exploitation would likely appear as suspicious local administrative activity around boot settings, Secure Boot state, BitLocker protector state, EFI partition access, and unexpected pre-boot component changes.

How to fix it

Apply the applicable Microsoft security updates for affected Windows versions as soon as they are available through Windows Update, Microsoft Update Catalog, WSUS, Intune, Configuration Manager, or other enterprise patching tools. No exact fixed build numbers were provided in the input, so remediation should be validated against Microsoft’s official security update guidance for this CVE and the relevant Windows release. Also apply OEM firmware/UEFI updates where available, keep Secure Boot enabled, ensure Secure Boot DB/DBX revocation data is current, and verify BitLocker protectors remain enabled after patching. Reduce exploitability by limiting local administrative rights, blocking untrusted boot/firmware management tools, enforcing application control where practical, preventing unauthorized physical access, and monitoring or restricting access to the EFI System Partition. For systems that cannot be patched promptly, prioritize compensating controls on high-value assets: isolate management access, require MFA for privileged logons, enforce least privilege, monitor boot configuration changes, and consider temporarily removing the asset from sensitive workflows until updated.

How to confirm the fix worked

Confirm that each affected Windows system has installed the Microsoft security update that addresses this vulnerability for its OS version and servicing channel. Validate patch deployment through Windows Update history, enterprise patch-compliance tooling, vulnerability scanners, or Microsoft Update Catalog KB verification. Confirm system security posture after remediation by checking Secure Boot state with PowerShell, verifying BitLocker protectors are enabled, reviewing virtualization-based security status where used, and confirming there are no unauthorized boot configuration changes. Reboot systems after patching if required and verify that endpoint protection, BitLocker, and Secure Boot telemetry return to expected states. For firmware-dependent platforms, verify the device is running the latest approved OEM UEFI firmware and that Secure Boot revocation databases are current.

Typical attack path

1. Gain local authenticated access to an affected Windows client or server.
2. Enumerate platform security state, including Secure Boot, BitLocker, boot configuration, and virtualization-based security status.
3. Invoke exploit logic or abuse the flawed UEFI protection path to bypass the intended security feature.
4. Modify boot-related settings, EFI System Partition contents, or security-control state to weaken pre-OS trust guarantees.
5. Reboot or trigger conditions needed for the altered boot state to take effect.
6. Use the weakened boot/security posture to persist, access sensitive data, evade endpoint controls, or disrupt recovery.

How to detect it

Hunt for evidence of local post-compromise activity targeting boot and firmware controls. Review Windows Security logs for unusual privileged logons, privilege assignment, process creation, and service creation around the time of suspected compromise, especially Event IDs 4624, 4672, 4688, 4697, and 7045 where command-line logging is available. Review Sysmon or EDR telemetry for access to the EFI System Partition, use of boot-management utilities, unsigned or unusual executables modifying boot settings, and abnormal writes under EFI paths. Check Microsoft-Windows-BitLocker logs for unexpected protector suspension, recovery events, or encryption state changes, and review Microsoft-Windows-Kernel-Boot, CodeIntegrity, SecureBoot, and DeviceGuard/Operational logs for changes to boot integrity, Secure Boot state, virtualization-based security, or code-integrity enforcement. Compare current boot configuration against a known-good baseline using bcdedit output, confirm Secure Boot remains enabled, and compare EFI System Partition file hashes against trusted vendor baselines where available. Investigate any unauthorized mounting of the EFI System Partition, unexpected changes to bootmgfw.efi or bootx64.efi, unexpected BitLocker suspension before reboot, or endpoint security alerts suppressed after a reboot. There are no known public exploit-specific indicators in the provided data, so detections should focus on behavioral evidence of UEFI, boot-chain, and platform-security tampering.

• bcdedit /set
• bcdedit /deletevalue
• bcdedit /enum firmware
• bcdedit /set testsigning on
• bcdedit /set nointegritychecks on
• mountvol /S
• mountvol.exe /S
• manage-bde -protectors -disable
• manage-bde -off
• reagentc /disable
• diskpart
• select volume
• assign letter=
• \\EFI\\Microsoft\\Boot\\bootmgfw.efi
• \\EFI\\Boot\\bootx64.efi
• \\EFI\\Microsoft\\Boot\\BCD
• \EFI\Microsoft\Boot\bootmgfw.efi
• \EFI\Boot\bootx64.efi
• \EFI\Microsoft\Boot\BCD
• Microsoft-Windows-BitLocker
• Microsoft-Windows-Kernel-Boot
• Microsoft-Windows-CodeIntegrity
• Microsoft-Windows-SecureBoot
• Microsoft-Windows-DeviceGuard/Operational
• Secure Boot state is OFF
• BitLocker protection suspended
• BitLocker Drive Encryption was suspended

What your security team should do

• Prioritize patching for privileged administrator workstations, identity infrastructure, servers, developer workstations, kiosks, and devices handling sensitive or regulated data.
• Use enterprise patch tooling to identify affected Windows 10, Windows 11, and Windows Server systems and track update compliance against Microsoft’s official fixed updates.
• Audit local administrator membership and remove unnecessary local privileges, because exploitation requires authenticated local access.
• Monitor for suspicious boot configuration, Secure Boot, BitLocker, EFI System Partition, and firmware-related activity before and after remediation.
• Review EDR/SIEM telemetry for unusual use of bcdedit, mountvol, manage-bde, reagentc, diskpart, PowerShell, or firmware-management utilities by non-administrative or unexpected users.
• Ensure Secure Boot is enabled, BitLocker protectors are active, and Secure Boot DBX updates are deployed where applicable.
• Treat unexplained Secure Boot disablement, BitLocker suspension, or EFI partition modification as high-priority incident-response events.
• Because EPSS and KEV signals are currently low, schedule broad remediation through normal high-priority patch cycles, but accelerate deployment on high-value and hard-to-recover systems.