Researchers at ESET discovered that Microsoft’s Secure Boot has been effectively broken for most of its existence. The culprit is a set of forgotten UEFI shim bootloaders that Microsoft signed years ago and never revoked. Eleven specific shims, all version 0.9 and below, can be used to bypass Secure Boot on virtually any system, and Microsoft only patched them in June 2026.
What happened
Secure Boot is supposed to ensure that only trusted code runs during the boot process. The chain of trust starts with a hardware root of trust and extends through the bootloader, the OS kernel, and beyond. Microsoft, as the platform vendor for UEFI Secure Boot on x86 systems, controls which bootloaders are trusted by signing them with its UEFI CA 2011 certificate.
The problem is that Microsoft signed UEFI shim bootloaders for Linux distributions years ago and never revoked the older versions. ESET researchers found that shims at version 0.9 and below – some dating back to approximately 2012 – contain no meaningful boot path validation. An attacker with local access can simply drop one of these old shim files onto a system and boot arbitrary unsigned code, completely bypassing Secure Boot.
Timeline: The vulnerable shims have existed for approximately 13 of Secure Boot’s 14-year history. Microsoft finally revoked them in its June 2026 Patch Tuesday update by adding them to the UEFI dbx (forbidden signatures database). Two CVEs were assigned: CVE-2026-8863 and CVE-2026-10797.
Why this matters
This is not an edge case. Secure Boot is the foundation of platform trust on modern Windows and Linux systems. It is what prevents bootkits, rootkits, and other low-level malware from persisting across reboots. If the foundation is rotten, everything built on top of it is suspect.
The scope is broad. The shims were signed by Microsoft’s UEFI CA 2011, which is trusted by essentially all UEFI firmware on x86 hardware. That means the bypass works on any system that has not received the June 2026 dbx update – Windows and Linux alike. ESET estimates that the vast majority of systems in the field were vulnerable before the patch.
What makes this particularly bad is how easy the exploit is. There is no complex chain of vulnerabilities to chain together. No privilege escalation needed. You copy a file, you bypass Secure Boot. The shim bootloaders are publicly available – they were hosted on distribution websites for years. An attacker who has already gained local access (or who can trick a user into booting from removable media) can disable the entire Secure Boot trust model with a single file.
How the fix works
Microsoft’s June 2026 Patch Tuesday included a dbx update that adds the 11 vulnerable shim versions to the UEFI forbidden signatures database. Once applied, UEFI firmware will refuse to load those specific shim bootloaders, restoring the Secure Boot chain of trust.
The dbx update is delivered through Windows Update for Windows systems. Linux distributions that support Secure Boot will also pick up the revocation through their own update mechanisms. The fix is straightforward to apply but requires users to actually install it – and given how many systems skip updates, the vulnerable shims will remain usable on unpatched machines for years.
One complication: the same shim revocation can cause boot failures on older Linux installations that relied on the vulnerable shim versions for their Secure Boot chain. Organizations running legacy Linux deployments should test the dbx update in a staging environment before rolling it out broadly.
What this means for system administrators
If you manage Windows or Linux systems, here is what to do:
- Apply the June 2026 Patch Tuesday updates on all managed systems. The dbx update is included in the normal cumulative update, not a separate install.
- Verify dbx application by checking the UEFI firmware settings on a sample of systems after the update. Some firmware implementations handle dbx updates differently.
- Inventory any custom UEFI shim usage in your environment. Organizations using signed bootloaders for internal tools should audit their own signing practices and ensure old certificates are revoked.
- Test on legacy Linux installations before broad rollout. Systems using old shim versions for Secure Boot may fail to boot after the revocation and need a bootloader update.
The broader picture
This vulnerability is a reminder that cryptographic trust models are only as good as their key management. Microsoft signed these shims over a decade ago for legitimate reasons – to support Linux booting on Secure Boot-enabled hardware. The system worked exactly as designed: the shims were signed, tested, and deployed. What failed was the revocation process. Once a signed binary is out in the world, it cannot be taken back. It can only be blacklisted, and blacklisting requires finding the problem first.
The shims sat forgotten for 13 years because nobody was looking for this kind of vulnerability. ESET specifically targets UEFI boot security research, and even they were surprised that such old code was still trusted. The lesson for the industry is that signing certificates need active lifecycle management, not just issuance and revocation. A signing key that is valid for “forever” is a security risk, not a feature.