Windows Secure Boot CVE-2026-49783

Exploitation requires local access to an affected Windows/Windows Server host and at least low-level privileges (CVSS PR:L), with no user interaction (UI:N); the attacker must be able to run code locally that manipulates or supplies a boot component which then passes the flawed Secure Boot validation. The vulnerability cannot be triggered remotely or unauthenticated - the local attack vector (AV:L) and required privileges are the primary limiting factors, meaning an adversary must already have a foothold on the machine. Secure Boot must be the enforced trust mechanism on the target (UEFI systems with Secure Boot enabled); systems in legacy/CSM boot or with Secure Boot disabled are not protected by, and thus not meaningfully bypassing, this control.

The CVSS 3.1 base score is 7.8 (High) with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - local attack vector, low complexity, low privileges required, no user interaction, and high confidentiality/integrity/availability impact once the boot trust chain is subverted. This is a genuine defense-in-depth control failure but not an internet-facing remote threat: the attacker must already be able to run code locally with at least low privileges, which meaningfully constrains mass exploitation. No EPSS score, SSVC decision, KEV listing, or POC was provided, so exploitation probability cannot be quantified from the data; the absence of a KEV entry and any public exploit suggests this is not currently under widespread active exploitation. Prioritization should be driven by the Secure Boot bypass class rather than raw score - such flaws are high-value for advanced/persistent adversaries (bootkits, tamper of BitLocker's trust assumptions) even when broad opportunistic use is unlikely. Note a caveat: the impact metrics C:H/I:H/A:H reflect the consequence of a compromised boot chain, which is somewhat higher than a pure security-feature-bypass sometimes warrants - treat the numeric confidentiality/availability weighting as an upper-bound framing pending vendor detail.

An attacker who has already gained low-privileged local code execution on a targeted workstation or server - for example via a prior phishing foothold or an insider - abuses the improperly implemented Secure Boot check to load a tampered or unsigned boot component that the firmware should have rejected. This establishes a bootkit-level foothold that survives OS reinstallation and can weaken BitLocker's integrity assumptions. No public proof-of-concept was provided, and the local, low-complexity vector means exploitation is realistic only after initial access is obtained.