Microsoft Secure Boot Flaw Exploitable for Decade, Researchers Find

A fundamental security feature designed by Microsoft to protect computers from malicious firmware infections has been demonstrably bypassable for nearly its entire 14-year history. Researchers at security firm ESET discovered that outdated, yet still trusted, firmware components known as "shims" could be used to circumvent Microsoft's UEFI Secure Boot protection. This oversight, involving 11 specific firmware images at least one dating back to 2013, persisted because Microsoft failed to revoke these compromised components.

Secure Boot, introduced in 2012 as part of the UEFI standard, aims to prevent bootkits—malware that infects the crucial pre-operating system boot process. By ensuring only digitally signed and trusted software executes during startup, it acts as a vital safeguard. However, ESET's findings reveal that attackers could leverage these old, unrevoked shims with relatively basic techniques to install malicious firmware that survives OS reinstallation or even hard drive swaps. These shims are designed to extend Secure Boot's trust to non-Windows environments like Linux distributions and utility software.

"What makes these old shims dangerous is not a novel vulnerability," stated ESET researcher Martin Smolár. "It’s that no new vulnerability is needed to bypass UEFI Secure Boot. An attacker needs no complicated exploitation primitives—only a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims work. That is enough to bypass such an essential security feature as UEFI Secure Boot." The discovery highlights a significant lapse in Microsoft's oversight of the code-signing process for these critical components.

Complexity Hinders Security Updates

The vulnerability arises from Microsoft's failure to revoke specific, vulnerable shim binaries. These shims act as secondary trust anchors, signed by Microsoft and then used to authenticate subsequent bootloaders and utilities. When vulnerabilities were discovered in these shims, Microsoft's process for revoking them failed in numerous cases for over a decade. The company only recently revoked the affected images in its June 2026 patch release, after ESET brought the issue to attention.

Microsoft has not yet provided a detailed explanation for this lapse, but the complexity of the Secure Boot mechanism itself is a likely contributing factor. The system relies on intricate databases (db for trusted items and dbx for revoked items) and newer revocation methods like SBAT (Secure Boot Advanced Targeting) and Secure Boot Security Version Number (SVN). These methods aim to manage revocation more efficiently, especially given the limited space for the dbx list. SBAT and SVN allow for the revocation of entire versions of software, rather than individual binaries. However, this complexity also means that managing and updating these trust lists can be prone to errors.

The identified shims authorized secondary components known to be vulnerable. For instance, an Oracle shim was found to sign a binary vulnerable to CVE-2015-5381. Many of these older shims predated the implementation of protections like SBAT and MOK deny lists, or they contained their own code vulnerabilities. The failure to revoke them meant that systems relying on these specific shims remained exposed to known risks.

While Windows 11 Secured-core PCs in their default configuration are likely unaffected, and users who installed Microsoft's June 2026 updates are now protected, the decade-long exposure is a stark reminder of the challenges in maintaining firmware security. Linux users are advised to consult their distribution vendor or the Linux Vendor Firmware Service for guidance. The implications of this widespread, long-standing vulnerability underscore the critical need for robust oversight and simplified update mechanisms within firmware security protocols.