Eleven Old Microsoft-Signed UEFI Shims Bypass Secure Boot
ESET researchers discovered that eleven older versions of Microsoft-signed UEFI boot shims (versions 0.9 and below) can bypass Secure Boot protections, with Microsoft revoking certificates for these specific shims.
ESET researchers have uncovered a significant vulnerability affecting UEFI Secure Boot, a critical security feature designed to protect the boot process of computers. Eleven older versions of Microsoft-signed UEFI boot shims, specifically versions 0.9 and below, have been found capable of bypassing these protections. These shims are intended to allow third-party bootloaders, such as those used by Linux distributions, to run securely on systems with Secure Boot enabled. However, due to their age and the vulnerabilities they contain, these specific shims undermine the very security they are meant to uphold.
Microsoft has acknowledged the issue and, in its June 9, 2026 Patch Tuesday update, revoked the digital certificates associated with these vulnerable shims. This action prevents the shims from being trusted by systems that actively check for revoked certificates. The affected shims are trusted by any UEFI system carrying Microsoft’s third-party certificate, the Microsoft Corporation UEFI CA 2011, and their behavior is independent of the operating system installed. The danger lies in the fact that an attacker can copy one of these old shims onto a target machine, along with a matching second-stage loader, and the boot chain will accept it, effectively bypassing Secure Boot.
The vulnerability stems from the way these shims function. A shim acts as a minimal loader that Microsoft vets and signs once. It then vouches for the next stage in the boot process, typically a bootloader like GRUB 2, using a vendor certificate embedded within it. GRUB 2, in turn, verifies the operating system's kernel against that same certificate. The problem arises when the second-stage loaders themselves contain known vulnerabilities, especially in older versions of components like GRUB 2.
For instance, one reported Oracle Linux shim trusts a GRUB 2 binary from an older Oracle Linux 7.1 installation media that is vulnerable to CVE-2015-5281. This flaw allows local users to bypass Secure Boot restrictions and execute non-verified code via a crafted multiboot or multiboot2 module. An attacker could easily exploit this by creating an unsigned multiboot2 kernel image, placing it on the EFI System Partition alongside the old shim and GRUB 2, and then loading it with a single command during boot.
Furthermore, these older shims lack crucial security features that have been added to the shim project in later versions. Features like MOK (Machine Owner Key) denylist enforcement, which allows a system to reject a revoked key, were introduced after version 0.9. Similarly, support for Secure Boot Advanced Targeting (SBAT), which enhances revocation management, arrived much later. Shims built before these features were implemented will ignore matching revocations, allowing attackers to potentially swap a patched shim for an older, vulnerable Microsoft-signed one, thereby loading binaries that current security policies would otherwise block.
A separate, related flaw, now tracked as CVE-2026-10797, was fixed upstream nearly a decade ago but never received a CVE ID until this report. The old signed shims carrying this flaw were never revoked. This vulnerability exploits how signed PE binaries record their signature length in two locations. The affected shims read one location for revocation checks and another for signature verification. By tampering with the WIN_CERTIFICATE structure of a second-stage loader, an attacker can trick the revocation check into using the wrong bytes, allowing a certificate that should have been revoked to slip through. This bypass specifically affects certificate-based revocations where the second-stage loader is signed by a certificate embedded in the shim; hash-based revocations remain effective.
While the Microsoft UEFI CA 2011 certificate itself expired on June 27, 2026, this expiration does not affect Secure Boot verification for bootloaders signed with it prior to expiration. Such bootloaders remain trusted as long as the certificate is present in the system's trusted database (db) and its hash is not listed in the revoked database (dbx). Microsoft continued signing submissions with this certificate until its expiration date.
To mitigate these risks, users must ensure that the latest UEFI revocations are applied. Windows machines typically receive dbx updates automatically, but ESET has provided PowerShell commands for elevated users to check for the presence of the eleven revoked hashes. Linux systems can obtain the update via the Linux Vendor Firmware Service and verify the result using the uefi-dbx-audit script. Windows 11 Secured-core PCs should have third-party signing disabled by default. The shim-review repository documents shims submitted for signing since 2017, but no comprehensive record exists for earlier submissions, making it impossible to determine the exact number of vulnerable shims still in circulation. Revoking these eleven shims is a crucial step, and implementing version-based revocation mechanisms like SBAT will aid future cleanup efforts.