Windows Secure Boot CVE-2026-45654

Exploitation requires local code execution on the target Windows system with high privileges (administrator/SYSTEM, per CVSS PR:H), meaning the attacker must already be authorized on the machine - this is not a remote or unauthenticated bug. No user interaction is needed once the attacker is on the host (UI:N), and the attack complexity is low (AC:L), but the AV:L vector rules out network-based or drive-by exploitation. The bug therefore acts as a post-exploitation primitive for persistence and defense evasion against Secure Boot, and is gated by whatever Windows builds are listed in the MSRC advisory; physical-attack variants (e.g., evil-maid against a powered-off but unencrypted boot partition) are plausible given the boot-stage nature but are not explicitly confirmed by the supplied data.

The CVSS 3.1 vector (AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N) describes a local attack requiring high privileges but no user interaction, with a scope change that explains the elevated 7.9 score despite the local/PR:H constraints - exploitation crosses from an administrative OS context into the firmware/boot trust domain. EPSS data was not provided, the vulnerability is not in CISA KEV, and no POC was referenced, so exploitation is best characterized as no public exploit identified at time of analysis. Practically, this is a post-compromise persistence and defense-evasion enabler (classic bootkit territory) rather than an initial-access bug; prioritization should be high for endpoints that rely on Secure Boot as the basis for BitLocker, VBS, or Credential Guard, and moderate for systems where an attacker already needing admin makes the marginal risk smaller. Key data gaps: exact affected Windows SKUs/builds, KB number, EPSS score, and whether a workaround exists - all must be retrieved from the MSRC advisory.

An attacker who has already obtained local administrator privileges on a Windows host - for example via a phishing-delivered loader that escalated through a separate flaw - invokes the vulnerable Secure Boot pathway to load an unsigned or improperly validated boot component. With Secure Boot's policy enforcement bypassed, they install a bootkit or tampered bootloader that survives reboots and reinstalls, neutralizing measured-boot-based defenses and exfiltrating data protected by BitLocker key material exposed during early boot. No public POC is referenced, so the scenario is currently theoretical based on the CVSS vector and CWE-284 classification.