CVE-2026-45588

What it actually does

This vulnerability is a Windows Secure Boot protection-mechanism failure that allows a local, authorized attacker with high privileges to bypass Secure Boot’s trust enforcement. At a technical level, successful exploitation can allow boot-time execution of code or components that should not be trusted by the platform, undermining the chain of trust that normally protects the Windows boot process. Because exploitation requires local administrative-level access, this is primarily a post-compromise privilege, persistence, and defense-evasion issue rather than an initial remote access vulnerability.

Why it matters to the business

If exploited, this flaw can allow an attacker who already has high local privileges to weaken one of the core protections that helps prevent bootkits, rootkits, and tampering with the operating system before security tools start. The practical business risk is harder-to-detect persistence, reduced confidence in endpoint integrity, possible credential or data compromise after reboot, and increased incident response cost because affected systems may require deeper forensic validation or reimaging. The CVSS score is high, but current public exploitation signals are low: EPSS is low, no known CISA KEV listing is present, and no public exploit maturity is reported. Organizations with large Windows desktop or server fleets should still prioritize patching because the affected product range is broad across Windows 10, Windows 11, and Windows Server releases.

How an attack unfolds

An attacker first needs to obtain local administrative or similarly high-privileged access to an affected Windows system. After gaining that level of access, the attacker can attempt to tamper with the boot trust path, boot configuration, EFI System Partition contents, Secure Boot-related policy, or boot components in a way that takes advantage of the Secure Boot protection failure. The attacker then triggers or waits for a reboot so that malicious or unauthorized boot-time code can execute before the normal operating system security stack is fully active. Once running at boot time, the attacker may attempt to hide from endpoint defenses, disable security controls, preserve access across reboots, or prepare the system for further credential theft and lateral movement. No named threat actors or ransomware campaigns are currently provided for this CVE, and there is no known KEV status, so detection should focus on generic Secure Boot bypass and boot-chain tampering behaviors rather than campaign-specific indicators.

How to fix it

Apply Microsoft security updates for all affected Windows versions as soon as they are available through Windows Update, Microsoft Update Catalog, WSUS, Intune, or other enterprise patch management tooling. The affected product set includes Windows 10 versions 1607, 1809, 21H2, and 22H2; Windows 11 versions 23H2, 24H2, 25H2, and 26H1; and Windows Server 2012, 2016, 2019, 2022, and 2025. No exact fixed build numbers were provided in the input, so remediation should be validated against Microsoft’s official advisory and installed cumulative update history for each supported release. Where applicable, also ensure Secure Boot is enabled, firmware is up to date, revocation database updates such as dbx updates are deployed when required by Microsoft or the device vendor, and BitLocker recovery planning is in place before boot-chain or firmware-related updates. As compensating controls, restrict local administrator rights, monitor and block unauthorized use of boot configuration tools, prevent unauthorized writes to the EFI System Partition, enforce device encryption, and require physical security controls for endpoints and servers.

How to confirm the fix worked

Confirm that each affected system has installed the Microsoft cumulative/security update that addresses this vulnerability for its Windows release. Validate OS build and update installation through enterprise patch inventory, Windows Update history, PowerShell, or endpoint management reporting. Confirm Secure Boot status with supported Windows tooling such as System Information, PowerShell Secure Boot checks, or device management inventory. Review firmware/UEFI and dbx update status where applicable. Test a representative sample of systems after patching to confirm they boot normally, BitLocker recovery is not unexpectedly triggered, and Secure Boot remains enabled. For exposure validation, identify systems running affected Windows versions that are missing the relevant update or have Secure Boot disabled, misconfigured, or unsupported.

Typical attack path

1. Compromise the system through another vulnerability, stolen credentials, physical access, or existing administrative access.
2. Escalate or obtain local high privileges required to modify boot-related settings or protected disk areas.
3. Inspect Secure Boot state, firmware mode, BitLocker state, and boot configuration.
4. Modify boot configuration, EFI System Partition contents, Secure Boot policy, or boot-related components to exploit the Secure Boot bypass condition.
5. Reboot the system so the manipulated boot path is evaluated.
6. Execute unauthorized boot-time code or load an untrusted component before normal operating system protections are fully active.
7. Use boot-level persistence or defense evasion to hide activity, disable controls, or support follow-on compromise.

How to detect it

To determine whether this was already exploited, hunt for evidence of boot-chain tampering rather than relying on a single exploit signature. Review Windows Security logs for privileged process creation involving boot and disk utilities, especially bcdedit.exe, bootsect.exe, mountvol.exe, diskpart.exe, reagentc.exe, powershell.exe, cmd.exe, and vendor firmware tools. Review Microsoft-Windows-Kernel-Boot, Microsoft-Windows-CodeIntegrity, Microsoft-Windows-BitLocker, Microsoft-Windows-TPM-WMI, and system event logs for Secure Boot state changes, boot integrity validation errors, unexpected recovery prompts, boot configuration changes, or failed trusted boot measurements. Examine endpoint detection telemetry for writes to the EFI System Partition and changes under EFI boot paths. Compare EFI System Partition file hashes and timestamps against known-good baselines for the same OS build and hardware model. Look for administrative activity shortly before reboot events, followed by security control failure, EDR sensor outage, BitLocker recovery, or unexpected changes in Secure Boot state. Because no public exploit maturity or campaign-specific threat actor data is provided, SOC rules should emphasize behavioral indicators: high-privilege modification of boot configuration, mounting of the EFI System Partition, replacement of boot manager files, and anomalous reboots following those actions.

• bcdedit.exe
• bootsect.exe
• mountvol.exe
• diskpart.exe
• reagentc.exe
• bcdboot.exe
• \EFI\Microsoft\Boot\bootmgfw.efi
• \EFI\Microsoft\Boot\BCD
• \EFI\Boot\bootx64.efi
• \EFI\Microsoft\Boot\SecureBootRecovery.efi
• Secure Boot Violation
• Secure Boot state is off
• Microsoft-Windows-Kernel-Boot
• Microsoft-Windows-CodeIntegrity
• Microsoft-Windows-BitLocker
• Microsoft-Windows-TPM-WMI
• BitLocker recovery
• EFI System Partition

What your security team should do

• Prioritize patching internet-adjacent administrator workstations, privileged access workstations, domain administration systems, virtualization hosts, certificate/identity infrastructure, and high-value servers running affected Windows releases.
• Inventory affected Windows 10, Windows 11, and Windows Server assets and identify systems where Secure Boot is disabled or unknown.
• Deploy the applicable Microsoft security update through standard patch management and track compliance by OS release and build.
• Validate Secure Boot, BitLocker, TPM, and firmware health on representative devices after patching, especially where boot-chain updates are applied.
• Restrict local administrator privileges and monitor privileged interactive logons because exploitation requires high local privileges.
• Create detections for suspicious modification of boot configuration, EFI System Partition files, Secure Boot variables, and unexpected use of bcdedit.exe, bootsect.exe, mountvol.exe, diskpart.exe, reagentc.exe, or firmware update utilities.
• Investigate any endpoint showing Secure Boot state changes, unexpected BitLocker recovery events, or boot integrity failures around the same time as suspicious administrative activity.
• For systems with credible boot-chain compromise indicators, consider offline forensic acquisition or reimaging from trusted media rather than relying only on in-OS cleanup.