Secure Boot, one of the primary security mechanisms protecting Windows and Linux systems from early-stage malware, could be bypassed for nearly its entire existence, researchers at ESET have revealed. The flaw remained undetected for more than ten years because Microsoft continued to trust outdated shim bootloader images that contained known vulnerabilities.
The shim components were originally created to extend Secure Boot support to Linux distributions and pre-OS utilities. Microsoft signed these files with its own certificate, allowing UEFI firmware to execute them during the boot process. ESET identified 11 vulnerable shim images; the oldest known sample appeared in 2013, only one year after Secure Boot was introduced.
Although the vulnerabilities in these components had been publicly known for years, Microsoft never added the corresponding hashes or certificates to the UEFI revocation database (dbx). As a result, systems continued to trust the old files, enabling attackers to break the signature verification chain and install persistent bootkits.
The attack required no new exploits. An adversary only needed a copy of one of the still-valid legacy shim files and basic knowledge of the UEFI boot process. Once executed, the compromised shim could disable subsequent signature checks and load malicious code before the operating system itself started.
Because UEFI firmware does not bind a Microsoft-signed shim to any particular operating system, the same vulnerable images could be used against both Linux and Windows machines. After bypassing Secure Boot, attackers could deploy bootkits such as LoJax, MosaicRegressor, CosmicStrand, or BlackLotus, some of which have been linked to nation-state actors.
The affected files were listed by CERT and included shims from Red Hat, openSUSE, Oracle, and third-party vendors such as Finnish company PC-Doctor, which was used in national examination systems. Several of the images predated modern revocation mechanisms like SBAT (Secure Boot Advanced Targeting) and SVN (Security Version Number), and some failed to honor Machine Owner Key deny lists.
Microsoft finally revoked the 11 vulnerable shims in its June security updates after receiving the report from ESET. The company is responsible for maintaining the central trust store for the UEFI ecosystem, yet the incident demonstrates how difficult it remains to track and revoke thousands of signed boot components over time.
Windows 11 Secured-core devices were likely protected by default thanks to additional hardware-backed policies, but general Windows and Linux users are advised to verify that their firmware has received the updated revocation lists via the Linux Vendor Firmware Service or the uefi-dbx-audit script.
