Windows Secure Boot EUVD-2026-35524

Attacker must already have high-privilege local access to the Windows host (administrator or SYSTEM, per CVSS PR:H and AV:L) and the ability to write to UEFI/Secure-Boot-controlled boot components and trigger or wait for a reboot; no user interaction is required (UI:N). Limiting factors: the bug is not remotely reachable, cannot be triggered by a standard user or low-privileged service account, and yields no direct availability impact (A:N) - its value is integrity of the boot chain, not crash or DoS. Realistic risk is therefore confined to scenarios where an attacker has already achieved admin-level code execution or has physical possession of the device.

The CVSS vector AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N tells a consistent story: exploitation requires local access and already-high privileges (administrator/SYSTEM), which is a significant gating factor, but once those prerequisites are met the attack is low-complexity, needs no user interaction, and produces a scope change reflecting that the broken boundary is the firmware/Secure Boot trust domain rather than the OS itself. There is no CISA KEV entry, no EPSS score provided, and no POC identified at time of analysis, so this is not a mass-exploitation candidate; however, Secure Boot bypasses are historically high-value to APT and ransomware actors (BlackLotus-class bootkits) because they enable persistence that survives OS reinstall and evades EDR loaded after boot. Treat as a high-priority patch for endpoints where physical or admin compromise is part of the threat model (executives, domain controllers, kiosks, recovered/stolen devices), and a moderate priority elsewhere - the PR:H requirement means it is primarily a post-compromise escalation-of-trust issue, not an initial-access vector.

An attacker who has already obtained local administrator or SYSTEM privileges on a Windows endpoint - for example via a phishing-delivered loader or a stolen laptop - runs a tool that abuses the flawed Secure Boot check to write a malicious bootloader or to load an unsigned driver early in the boot sequence. On the next reboot the tampered component executes before Windows and any EDR agent, establishing a bootkit that persists across OS reinstalls and is invisible to in-OS scanners. No public exploit identified at time of analysis, but the BlackLotus and BlackEnergy bootkit families demonstrate this attack pattern is well within reach of skilled adversaries once a Secure Boot weakness is documented.