ESET researchers have found 11 old Microsoft-signed UEFI shim bootloaders that let attackers bypass Secure Boot entirely. The bootloaders date back to 2013, version 0.9 and earlier, and Microsoft never revoked their signatures.
Secure Boot was introduced with Windows 8 in 2012 as a hardware-level protection. It checks that only trusted, signed bootloaders run during system startup. The idea is to stop bootkits and rootkits from loading before the OS even starts. But if an old signed bootloader has known vulnerabilities and Microsoft never revokes its certificate, then Secure Boot is not doing its job.
That is exactly what happened here.
How the bypass works
The vulnerable shims are UEFI bootloaders originally signed for Linux distributions. They were signed by Microsofts UEFI CA 2011 certificate, which almost every x86 machine ships with. The shims at version 0.9 have bugs that let an attacker load unsigned code during the boot process. Since the shim is legitimately signed, the UEFI firmware trusts it, and the malicious code runs with the same privileges as the OS kernel.
The attack does not require physical access. An attacker who has already gained local access on a machine can boot into a vulnerable shim, bypass Secure Boot, and load a bootkit that persists below the OS level. Traditional antivirus cannot see these bootkits because the OS itself is compromised.
And the scope is not limited to Windows. Any UEFI-based system that trusts Microsofts 2011 CA certificate is vulnerable, including Linux machines. This is a cross-platform problem because the trust chain lives in the UEFI firmware, not in the OS.
Why it went unnoticed for a decade
The shims were signed for legitimate Linux boot purposes. When vulnerabilities were discovered in those old versions, the normal process is for Microsoft to add them to the UEFI Forbidden Signature Database (DBX) so the firmware rejects them. But someone dropped the ball. The vulnerable shims were never added, so they continued to be trusted by every UEFI system for years.
ESET found the issue during a broader audit of UEFI shim security. They reported it to Microsoft, and Microsoft finally addressed it in the June 2026 Patch Tuesday updates by updating the DBX to revoke the vulnerable bootloaders. That is CVE-2026-45654 if you want to track it.
What the patch actually does
The June 2026 update adds the vulnerable shim hashes to the UEFI Forbidden Signature Database (DBX). This tells the firmware: do not trust these specific bootloaders, period. But there is a catch: DBX updates require a UEFI firmware update from the hardware vendor. On managed systems, this gets pushed through Windows Update. On older or unmanaged machines, it may never arrive.
For the patch to be effective, the system needs both the Windows cumulative update AND the UEFI DBX update. Microsoft distributes the DBX update as part of its firmware update catalog, but hardware vendors ultimately control when it reaches specific devices. If your laptop is three years old and the manufacturer stopped pushing firmware updates, you are relying on Microsofts OS-level revocation, which only works once Windows is already running.
Practical implications for developers and ops teams
This is the kind of vulnerability that sounds abstract until you think about what it enables. A bootkit installed through this bypass loads before the OS kernel. It can modify kernel data structures, hook system calls, and hide its own files and processes from the running OS. Even full disk encryption will not help because the bootkit intercepts the boot process after the disk is unlocked.
For enterprise environments, the mitigation is straightforward: apply the June 2026 Patch Tuesday updates and make sure UEFI firmware is current. For cloud workloads running on managed hypervisors, the provider should handle the DBX update. Virtual machines that use Secure Boot with standard Microsoft certificates are affected, but the hypervisor layer should receive the update independently.
For personal machines, check that firmware updates are being delivered. On Windows, go to Settings > Windows Update > Advanced options > Optional updates and look for firmware updates from your hardware vendor. On Linux, check if your distribution has shipped updated shim packages. The shim project has released version 16 with fixes, available from most distribution repositories.
What this says about supply chain trust
The uncomfortable part of this story is not the vulnerability itself. It is that the mechanism designed to prevent exactly this kind of problem (certificate revocation) failed for a decade because of an administrative oversight. Microsoft signed these bootloaders, then forgot about them. The UEFI security model depends on everyone doing their part: signers must track what they signed and revoke it when it becomes unsafe. When the signer forgets, the entire chain of trust weakens.
This is also a reminder that hardware security layers are only as strong as the administrative processes that maintain them. Secure Boot is not a one-time setup. It requires ongoing maintenance, and the DBX revocation list needs constant attention. A vulnerability from 2013 that nobody noticed until 2026 suggests the industry is not taking this maintenance seriously enough.
The ESET researchers are reportedly working on an open source tool to help detect vulnerable shim installations. That should be useful for anyone who wants to verify their systems without waiting for firmware updates.