What is the CVSS score of EUVD-2026-35514?

EUVD-2026-35514 has a CVSS 3.1 base score of 7.9 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N. EPSS exploitation probability: 0.1%.

Which versions of Windows Secure Boot are affected by EUVD-2026-35514?

A vulnerability in Windows Secure Boot permits high-privilege local attackers to bypass boot-time integrity protections and install persistent pre-OS malware resistant to standard system remediation…. A patch is available.

How to fix or mitigate EUVD-2026-35514?

Within 24 hours: Inventory Windows systems with Secure Boot enabled; review endpoint access logs for high-privilege local activity anomalies; activate monitoring for suspicious boot/firmware access. Within 7 days: Implement compensating controls including endpoint detection and response (EDR) with boot-level visibility, firmware integrity monitoring, and restricted high-privilege account access; prioritize assessment of critical systems. Within 30 days: Monitor vendor advisories for security updates; conduct full validation of affected endpoints; develop incident response procedures for potential pre-OS compromise.

Windows Secure Boot EUVD-2026-35514

| CVE-2026-45588 HIGH

Protection Mechanism Failure (CWE-693)

2026-06-09 secure@microsoft.com

GHSA-cx87-mv7w-77j9

Authentication Bypass Microsoft

7.9

CVSS 3.1 · NVD

Temporal: 6.9

Severity by source

NVD PRIMARY

7.9 HIGH

AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

CIRCL (temporal)

6.9 MEDIUM

cvss

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

Attack Vector

Local

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Patch available

Jun 09, 2026 - 19:03 EUVD

Analysis Generated

Jun 09, 2026 - 18:15 vuln.today

CVE Published

Jun 09, 2026 - 17:17 nvd

HIGH 7.9

DescriptionNVD

Protection mechanism failure in Windows Secure Boot allows an authorized attacker to bypass a security feature locally.

AnalysisAI

Security feature bypass in Windows Secure Boot enables a high-privileged local attacker to circumvent boot-time integrity protections, undermining the chain of trust that prevents unauthorized firmware and bootloader code from executing. The flaw (CWE-693, Protection Mechanism Failure) carries a CVSS 7.9 rating driven by scope change and high confidentiality/integrity impact, and no public exploit identified at time of analysis. Because Secure Boot is the foundation for downstream protections like BitLocker, Virtualization-Based Security, and Measured Boot, bypass enables persistent pre-OS implants that survive reimaging.

Technical ContextAI

Windows Secure Boot is a UEFI-based mechanism that validates the signatures of bootloaders, the Windows boot manager, and early-launch antimalware drivers against keys stored in firmware (PK, KEK, db, dbx) before allowing execution. CWE-693 (Protection Mechanism Failure) indicates the protection itself is logically defeated rather than crashed - typically through a flaw in signature validation, a trusted-but-vulnerable component in the allow-list, a TOCTOU in the verification path, or an unsanitized variable/policy that lets unsigned or revoked code load. Affected component is Microsoft's Secure Boot implementation on Windows; the only reference provided is MSRC advisory CVE-2026-45588 with no CPE strings supplied to enumerate exact builds.

RemediationAI

Apply the Microsoft security update referenced at https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45588 to all affected Windows systems (patch available per vendor advisory; exact KB and fix build were not provided in the input data and must be retrieved from MSRC). Because Secure Boot bypasses historically also require a UEFI dbx (forbidden signature database) update to revoke the vulnerable component, verify whether Microsoft has issued an accompanying dbx update and stage its deployment carefully - dbx updates have previously bricked dual-boot systems and older Linux distributions, so test on representative hardware first. Compensating controls while patching is in flight: restrict local administrator group membership (PR:H is required to exploit, so reducing who holds admin sharply reduces the attack surface), enforce LAPS, enable BitLocker with TPM+PIN so that an attacker with admin must still survive a reboot challenge, and monitor for unexpected changes to UEFI variables and boot configuration via endpoint telemetry.