HIGH 7.9

CVE-2026-48568: Windows Secure Boot Protection Bypass (CVSS 7.9 HIGH)

CVE-2026-48568 is a high-severity vulnerability in Windows Secure Boot that allows a user with administrator or higher privileges to bypass a key security mechanism on their local system. Secure Boot is designed to prevent unauthorized code from running during system startup. This flaw breaks that protection, potentially enabling an attacker with elevated local access to load malicious code earlier in the boot process than normal security controls would permit. The vulnerability affects a broad range of Windows 10 and Windows 11 versions, as well as Windows Server 2012 through 2025.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.9 HIGH · CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N
Weaknesses (CWE)
CWE-693
Affected products
24 configuration(s)
Published / Modified
2026-06-09 / 2026-06-17

NVD description (verbatim)

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

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

This vulnerability represents a protection mechanism failure (CWE-693) in the Windows Secure Boot implementation. The attack vector is local, requires high privileges (administrative level), and does not require user interaction. The impact is significant: an attacker can achieve both confidentiality and integrity violations by circumventing Secure Boot's validation chain. The scope is changed, meaning the attacker can impact security properties beyond the vulnerable component itself. Because Secure Boot operates at the firmware and early boot stage, a successful bypass creates a foundation for deploying code that persists across OS boots and evades normal runtime security controls.

Business impact

Compromise of Secure Boot enables firmware-level persistence and rootkit deployment. An attacker with admin credentials could establish a foothold that survives OS reinstallation or antimalware remediation efforts. In enterprise environments, this threatens endpoint security posture across fleets of machines, complicating incident response and compliance attestation. Organizations relying on Secure Boot as a preventive control for supply-chain integrity or boot-stage malware defense must treat this as a priority remediation to maintain the integrity of their security baseline.

Affected systems

The vulnerability affects Windows 10 versions 1607, 1809, 21H2, and 22H2; all current Windows 11 versions including 23H2, 24H2, 25H2, and 26H1; and Windows Server editions from 2012 through 2025. This represents a substantial installed base spanning consumer, enterprise, and server deployments. Administrators should inventory systems running these releases to prioritize patching efforts.

Exploitability

Exploitation requires high-level local system access (administrator or SYSTEM). This limits the threat actor pool to insiders, malware already running with elevated privileges, or an attacker who has compromised an administrative account. While not trivially exploitable by unprivileged users, organizations should assume that determined adversaries with internal network access or initial compromise footholds will attempt this bypass. The attack is straightforward once access requirements are met; no complex user interaction or race conditions are needed.

Remediation

Microsoft has released security updates addressing this vulnerability. Organizations should apply the latest cumulative updates or security-only patches for their respective Windows versions through Windows Update or WSUS. Verify against the official Microsoft Security Update Guide for the specific KB articles and patch versions corresponding to your deployed Windows builds. After patching, validate that Secure Boot remains enabled and functioning correctly in your environment.

Patch guidance

Obtain the latest security updates from Microsoft Update Catalog or through your organization's patch management system. For Windows 10, ensure you are on or past the patch date for this CVE (published 2026-06-09, modified 2026-06-17). For Windows 11 and Server editions, apply the latest available cumulative or monthly rollup. Test patches in a non-production environment first to confirm Secure Boot functionality and boot stability. For Server deployments, coordinate patching with your change management process to minimize downtime.

Detection guidance

Monitor for tampering with Secure Boot policy or configuration via Windows security event logs (particularly PowerShell execution logs if ConfigureSecureBoot or Set-SecureBootUEFI cmdlets are used without authorization). Firmware-level auditing tools and UEFI security monitoring solutions can detect unauthorized changes to the boot environment. Implement application whitelisting to restrict unsigned or improperly signed code from loading during boot. Ensure that Secure Boot status is regularly verified through configuration management tools to detect unexpected disablement.

Why prioritize this

This vulnerability merits high-priority remediation because it enables low-level system compromise that defeats many downstream security controls. Secure Boot is a foundational defensive layer; its bypass opens the door to persistent, stealthy attacks. The wide impact across Windows 10, 11, and Server products, combined with the integrity threat and the administrative access requirement common in many organizations, makes this a significant risk. Early patching prevents attackers from weaponizing this vector before it becomes more widely known.

Risk score, explained

The CVSS 3.1 score of 7.9 (HIGH) reflects a local attack vector with high privileges required, but with significant confidentiality and integrity impact across system boundaries. Although the attack requires administrator-level access, the consequences—complete compromise of the boot security chain—justify the HIGH severity rating. The modification to the score on 2026-06-17 may indicate refinement of impact assessment or attack complexity analysis by the vendor or assessment community.

Frequently asked questions

Do I need to be running Secure Boot for this vulnerability to affect me?

Yes. Secure Boot must be enabled for this vulnerability to be exploitable. If your systems do not use Secure Boot (e.g., systems booted in legacy BIOS mode), this particular flaw does not apply. However, modern Windows deployments and best practices strongly recommend Secure Boot be enabled; disabling it to avoid this vulnerability would weaken your overall security posture. The correct action is to patch, not to disable Secure Boot.

Can an unprivileged user exploit this?

No. The vulnerability explicitly requires high privileges (administrator or SYSTEM level). Unprivileged users cannot directly trigger this bypass. However, if an attacker has already compromised a privileged account or service, they can then use this flaw to persist and expand control at the firmware level.

Will antivirus or EDR detect an attack using this vulnerability?

Not necessarily. Because this vulnerability allows code to run at the boot stage before the OS kernel fully initializes, traditional antivirus and endpoint detection tools may be unable to detect or prevent the initial exploit. This is why Secure Boot itself is such a critical control—it is meant to prevent malicious code before antivirus engines even load. Patching this vulnerability is thus essential; detection is a secondary layer.

What should I prioritize first: patching or auditing Secure Boot status?

Both are important. Immediately audit your environment to identify which systems are running the affected Windows versions and that Secure Boot is enabled. Simultaneously, plan and execute patching. In high-risk environments or for critical systems, consider temporarily enhancing monitoring of boot-stage activities while patches are being rolled out. For servers, coordinate patching windows in advance given the infrastructure impact.

This analysis is provided for informational purposes. SEC.co does not guarantee the accuracy or completeness of vendor-provided patch or version information; always verify against official Microsoft Security Updates and your vendor's documentation. The vulnerability details and affected product list are accurate as of the source data publication date (2026-06-09). Organizations should conduct their own risk assessment based on their environment and threat model. No exploit code or weaponized proof-of-concept is provided herein. Consult your vendor documentation and security team before implementing mitigations in production environments. Source: NVD (public-domain), retrieved 2026-07-18. Analysis generated by SEC.co (claude-haiku-4-5).