Windows Secure Boot CVE-2026-69713

Exploitation requires local, interactive or remote access with high privileges (administrator-equivalent) on the target Windows system. The attacker must have write access to boot-critical storage or the ability to manipulate the third-party component in the Secure Boot dependency chain - this is not achievable from a standard user account. Secure Boot must be enabled on the system for this bypass to be relevant (systems without Secure Boot are not protected by the feature in any case). The vulnerability does not allow remote unauthenticated exploitation and cannot be triggered by a network-based attacker without first obtaining local high-privilege access. The limiting factors - local presence and administrator rights - significantly constrain realistic attacker population to post-compromise or insider scenarios.

The CVSS score of 4.4 (Medium) is commensurate with the constraint that exploitation requires local, high-privilege access (PR:H) - meaning the attacker must already be an administrator or have equivalent local control. The integrity-only impact (I:H, C:N, A:N) reflects that this is a security boundary bypass, not a direct data theft or denial-of-service primitive. EPSS data is not provided in the source intelligence, and the CVE is not listed in the CISA KEV catalog, indicating no confirmed active exploitation. No public proof-of-concept is cited. The real-world threat model is primarily a post-compromise persistence mechanism or a sandbox/policy escape: an attacker who already holds admin rights uses the Secure Boot bypass to load untrusted boot components that survive reimaging or evade security tooling that relies on Secure Boot attestation. The broad affected version surface (Windows 10 1607 through Windows Server 2025) elevates remediation priority for environments relying on Secure Boot for compliance attestation or TPM-based measured boot integrity.

An attacker who has already obtained local administrator privileges on a Windows endpoint - through credential theft, lateral movement, or a separate privilege escalation - leverages the vulnerable third-party Secure Boot dependency to replace or inject a boot component that Secure Boot would normally reject. This allows the attacker to persist a bootkit or rootkit that survives OS reinstallation and evades endpoint security products that depend on Secure Boot attestation to verify boot integrity. No public proof-of-concept is identified at time of analysis.