A decade-long vulnerability in Microsoft Secure Boot has been exposed, with security researchers identifying a collection of bootloader shims that allow attackers to bypass the protection mechanism entirely. The discovery, made by ESET, reveals that these shims—small pieces of software that act as intermediaries during the boot process—have been signing secondary components with known security flaws since at least 2015, undermining the foundational trust model of Secure Boot across both Windows and Linux environments.
What Are Secure Boot Shims and How Are They Vulnerable?
Secure Boot is a security standard designed to ensure that a device boots only using software that is trusted by the original equipment manufacturer. Shims are authorized, signed bootloaders that allow other, unsigned components to load during startup. The vulnerability arises when these shims themselves authorize binaries that contain known, exploitable vulnerabilities, or when the shims contain coding flaws that can be leveraged by an attacker to load untrusted code. ESET identified multiple shims, including one from Oracle, that sign a binary vulnerable to CVE-2015-5381, a flaw requiring minimal skill to exploit. Other shims fail to enforce modern protections such as MOK deny-list enforcement and SBAT enforcement, leaving systems open to attack even when those defenses are available.
The Decade-Long Bypass: What ESET Found
The scope of the vulnerability is extensive. ESET identified a rogue’s gallery of defective shims that have been operational for years. The Oracle shim, for example, authorizes a secondary component affected by CVE-2015-5381, a vulnerability with a low exploitation complexity. Other shims, released before the introduction of crucial security features like MOK deny-list enforcement and SBAT enforcement, do not support these protections, meaning they can be used to boot unsigned or malicious code without triggering security checks. Some shims contain vulnerabilities within their own codebase, further expanding the attack surface. Crucially, even the expiration of the Microsoft certificate that signed these shims, which occurred late last month, is insufficient to revoke them, as the underlying signed binaries remain valid and loadable.
Impact Across Windows and Linux Systems
The affected shims can be weaponized against both Windows and Linux machines, although Windows 11 Secured-core PCs in their default state are likely not vulnerable. For Windows users, installing the June update batch from Microsoft removes the risk by updating the Secure Boot revocation list. Linux users are advised to check the Linux Vendor Firmware Service or contact their distributor for updated firmware. Revocation status for specific systems can be verified using the uefi-dbx-audit script. The fundamental issue is that the Secure Boot ecosystem has become so complex that maintaining a complete and current revocation list is a formidable challenge, leaving gaps that attackers can exploit.
A Systemic Failure of the Secure Boot Model
The discovery has prompted sharp criticism from security experts. HD Moore, a firmware security expert and CEO of runZero, described the situation as a solid rebuke of the entire Secure Boot model. His concerns include Microsoft acting as the de facto root of trust for the entire UEFI platform, the inability of the revocation system to scale adequately, and the fact that components can continue to boot even after top-level certificates expire. The result, he noted, is a vast number of signed objects that bypass Secure Boot, some of which can themselves be used to boot other unsigned code, creating a cascade of trust failures. The entire ecosystem, Moore argued, is fundamentally broken and requires a complete reboot.
What Affected Users Should Do Now
For Windows users, the immediate step is to ensure that the June update batch from Microsoft has been installed. This update contains the necessary revocation data to block the vulnerable shims identified by ESET. Linux users should update their system firmware through the Linux Vendor Firmware Service or their distribution’s package manager. All users, regardless of platform, should verify their Secure Boot revocation status using the uefi-dbx-audit script. Beyond these immediate patches, organizations and individuals should consider adopting a multi-layered endpoint protection solution that includes behavioral analysis and real-time threat detection, as relying solely on Secure Boot is no longer sufficient. The core lesson from this decade-long oversight is that hardware-based trust mechanisms require rigorous, continuous auditing and a scalable revocation infrastructure to remain effective against determined adversaries.
