CVE-2026-48575: Windows 10 1607 Auth Bypass Vulnerability

CVE-2026-48575 Overview

CVE-2026-48575 is a protection mechanism failure [CWE-693] in Windows Secure Boot. An authorized attacker with local access and high privileges can bypass a security feature enforced during the boot process. The flaw affects a broad range of Windows desktop and server releases, including Windows 10, Windows 11, and Windows Server editions from 2012 through 2025. Microsoft published the advisory on June 9, 2026, and the issue carries a scope change indicating impact beyond the originally compromised component. Successful exploitation undermines the integrity of the trusted boot chain, which Secure Boot is designed to enforce against unauthorized firmware and bootloader components.

Critical Impact

An authenticated local attacker can bypass Secure Boot enforcement on affected Windows and Windows Server systems, breaking a core platform integrity control and enabling persistence below the operating system.

Affected Products

• Microsoft Windows 10 (1607, 1809, 21H2, 22H2) across x86, x64, and ARM64 builds
• Microsoft Windows 11 (23H2, 24H2, 25H2, 26H1) across x64 and ARM64 builds
• Microsoft Windows Server 2012, 2012 R2, 2016, 2019, 2022, and 2025

Discovery Timeline

• 2026-06-09 - CVE-2026-48575 published to NVD
• 2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-48575

Vulnerability Analysis

The vulnerability is classified as a protection mechanism failure under [CWE-693]. Secure Boot is intended to verify the cryptographic signatures of bootloaders and early-boot components against trusted keys stored in firmware. CVE-2026-48575 indicates that this verification path can be circumvented under specific conditions when the attacker is already authenticated on the host. The advisory describes the issue as a local security feature bypass with high impact on confidentiality and integrity, and a scope change that suggests the bypass affects components outside the immediate vulnerable boundary, such as firmware-resident code or boot-time data structures.

Root Cause

The root cause is an inadequate enforcement of Secure Boot validation logic during the boot sequence. Microsoft has not published low-level technical detail in the public advisory, but the CWE-693 classification indicates that a control intended to prevent unauthorized code execution at boot does not fully prevent the protected behavior. This typically points to flaws in signature verification, trust anchor handling, or revocation processing rather than a memory corruption defect.

Attack Vector

Exploitation requires local access and high privileges on the target system. No user interaction is required, and the attack does not traverse the network. A successful attacker can plant or load unsigned or revoked boot components that Secure Boot would normally reject, establishing pre-OS persistence and undermining downstream controls such as BitLocker measurements, Windows Defender System Guard, and virtualization-based security. Because the bypass occurs before the kernel is fully initialized, malicious code can run with the privileges of the firmware or early boot environment.

No public proof-of-concept exploit is available, and the issue is not listed in the CISA Known Exploited Vulnerabilities catalog. Refer to the Microsoft Security Update for CVE-2026-48575 for vendor-supplied technical context.

Detection Methods for CVE-2026-48575

Indicators of Compromise

• Unexpected modifications to EFI System Partition contents, including unsigned or unknown .efi binaries placed under \EFI\Microsoft\Boot\ or \EFI\Boot\.
• Changes to UEFI variables such as db, dbx, KEK, or PK that do not correspond to a sanctioned firmware or DBX update.
• TPM PCR measurements (PCR[0], PCR[2], PCR[4], PCR[7]) that diverge from a known-good baseline after reboot.
• Boot Configuration Data (BCD) entries referencing unexpected bootloaders or with nointegritychecks or testsigning enabled.

Detection Strategies

• Compare Secure Boot policy and DBX revocation list state across the fleet using Confirm-SecureBootUEFI and Get-SecureBootPolicy to find systems that drift from the approved baseline.
• Monitor administrative process creation events for tools that write to the EFI System Partition, modify UEFI variables, or invoke bcdedit with integrity-relaxing options.
• Correlate TPM attestation logs from Windows Defender System Guard and Microsoft Intune device health attestation to surface measured-boot anomalies.

Monitoring Recommendations

• Ingest Windows event logs from the Microsoft-Windows-CodeIntegrity/Operational and Microsoft-Windows-Kernel-Boot channels into a centralized SIEM for boot-integrity analytics.
• Track installation status of the June 2026 Microsoft security update across Windows 10, Windows 11, and Windows Server hosts and alert on missing patches.
• Establish alerts for any local privileged session that mounts the EFI partition or invokes mountvol, bcdedit /set, or reg.exe against boot-related registry keys.

How to Mitigate CVE-2026-48575

Immediate Actions Required

• Apply the Microsoft security update referenced in the MSRC advisory for CVE-2026-48575 to all affected Windows 10, Windows 11, and Windows Server systems.
• Restrict and audit local administrative access, since exploitation requires high privileges on the host.
• Validate that Secure Boot is enabled and enforced in firmware, and confirm DBX revocation lists are current after patching.

Patch Information

Microsoft addresses CVE-2026-48575 through cumulative security updates distributed via Windows Update, Microsoft Update Catalog, and Windows Server Update Services. Administrators should consult the Microsoft Security Update for CVE-2026-48575 for the specific KB articles per build, including separate packages for x64, x86, and ARM64 editions of Windows 10 (1607 through 22H2), Windows 11 (23H2 through 26H1), and Windows Server 2012, 2012 R2, 2016, 2019, 2022, and 2025. Some Secure Boot fixes require both an OS update and a DBX revocation list deployment to take full effect.

Workarounds

• Enforce the principle of least privilege so that day-to-day accounts cannot reach the local administrator or SYSTEM context required for exploitation.
• Enable BitLocker with TPM and PIN protectors to ensure tampering with the boot chain triggers recovery rather than silent compromise.
• Use Windows Defender System Guard and measured boot attestation through Microsoft Intune or equivalent to detect post-exploitation drift while patches are being deployed.
• Where supported, deploy the latest UEFI DBX update from the UEFI Forum revocation list to reject known-bad boot components.

# Verify Secure Boot status and patch state on Windows hosts
Confirm-SecureBootUEFI
Get-SecureBootPolicy
Get-HotFix | Sort-Object -Property InstalledOn -Descending | Select-Object -First 10