Forgotten UEFI Shims Undermining Secure Boot

Executive Summary

ESET researchers identified 11 old and forgotten UEFI shim bootloaders at versions 0.9 and below that can be used to bypass UEFI Secure Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Corporation UEFI CA 2011 third-party UEFI certificate authority (CA) certificate, regardless of the installed operating system (OS). These shims can be exploited to execute untrusted code during system boot, enabling attackers to deploy malicious UEFI bootkits even on systems with UEFI Secure Boot enabled. The vulnerable UEFI applications were revoked on Microsoft’s June 9th, 2026 Patch Tuesday.

The attack surface is not limited to vulnerabilities in the shims themselves. The discovered shims embed trusted, second-stage bootloaders (mostly GRUB 2), which may include outdated versions with known vulnerabilities such as CVE-2015-5281. Attackers can bring their own copy of vulnerable shims to any UEFI system with the Microsoft third-party UEFI certificate enrolled, making exploitation independent of whether the affected software is actually installed on the target system.

Key Takeaways

• ESET researchers discovered 11 old, Microsoft-signed, UEFI applications that allow bypassing UEFI Secure Boot on the majority of UEFI-based systems.
• An attacker exploiting one of these vulnerable applications can execute untrusted code during system boot, enabling deployment of malicious UEFI bootkits or other malware.
• Exploitation is not limited to systems with the affected software or OS installed—attackers can bring their own copy of the vulnerable binaries to any UEFI system with the Microsoft third-party UEFI certificate enrolled.
• All UEFI systems with Microsoft third-party UEFI signing enabled are affected (Windows 11 Secured-core PCs should have this option disabled by default).
• The vulnerable binaries were revoked by Microsoft in the June 9th, 2026 Patch Tuesday update.
• The deeper issue is visibility: pre-2017 Microsoft-signed shims lack transparent cataloguing, making comprehensive revocation difficult.
• Improved mechanisms like SBAT (Secure Boot Advanced Targeting) help manage revocation more efficiently than hash-based approaches.

UEFI Shim Bootloader and UEFI Secure Boot

UEFI Secure Boot

To understand the impact that vulnerable shims can have on UEFI Secure Boot-protected systems, we need to understand how UEFI Secure Boot works and how signed UEFI shim bootloaders extend the Secure Boot trust chain. When UEFI firmware loads a boot application—like Windows Boot Manager or a UEFI shim—it verifies the binary against two Secure Boot databases:

• db (allowed certificates and Authenticode hashes), and
• dbx (forbidden certificates and Authenticode hashes).

The image must be trusted by db and not listed in dbx; otherwise, the boot manager triggers a security violation. To make this work on newly purchased devices with UEFI Secure Boot enabled, most OEMs enroll a set of Microsoft UEFI certificates in the db database:

• Microsoft Windows Production PCA 2011 and Windows UEFI CA 2023 (used to sign Microsoft’s own UEFI boot applications).
• Microsoft Corporation UEFI CA 2011 and Microsoft UEFI CA 2023 (used to sign third-party UEFI boot software, such as Linux shims, recovery tools, and disk encryption utilities).

Microsoft plays a central role in securing most UEFI-based devices through its Windows Hardware Dev Center, where third-party vendors submit binaries for signing. Once approved, the signed files become trusted on the vast majority of UEFI systems.

UEFI Revocation (dbx)

UEFI Secure Boot’s revocation design is straightforward: when a previously trusted boot application turns out to be vulnerable, its PE authenticode hash is added to dbx, the Microsoft-managed forbidden-signatures database. While the original idea of revoking individual vulnerable binaries by hash might have been reasonable when Secure Boot was introduced, cases such as BootHole and BlackLotus demonstrate that this approach faces serious scalability challenges.

As part of the recent “BootHole” security incident [CVE-2020-10713], 3 certificates and 150 image hashes were added to the UEFI Secure Boot revocation database dbx on the popular x64 architecture. This single revocation event consumes 10kB of the 32kB, or roughly one third, of revocation storage typically available on UEFI platforms. Due to the way that UEFI merges revocation lists, this plus prior revocation events can result in a dbx that is almost 15kB in size, approaching 50% capacity.

Red Hat Bootloader Team SBAT Proposal

This pressure on dbx capacity prompted Microsoft and its partners to introduce additional, version-based revocation mechanisms:

• Secure Boot Advanced Targeting (SBAT) — used by shim, a UEFI bootloader for Linux, from version 15.3.
• Microsoft’s Secure Boot Security Version Number (SVN) — used by Windows Boot Manager (released in April 2024).

Where dbx revokes binaries by hash, SBAT and SVN revoke entire versions. When a vulnerability is found in a UEFI application supporting one of these version-based mechanisms, what needs to be kept out is every build up to and including the broken one—a version number captures this far more efficiently than a long list of hashes.

UEFI Shim Bootloader and Secure Boot

With Linux distributions supporting UEFI Secure Boot, the Secure Boot mechanism built around Microsoft keys introduces challenges. Every Linux distribution generates its own bootloader binaries, each with a different hash. Getting every Linux bootloader signed directly by Microsoft would be slow and impractical to maintain across all distributions.

The solution is a shim: a small, minimal first-stage bootloader that Microsoft vets and signs once, which then creates a secondary trust anchor for the rest of the Linux distribution-specific boot stack—usually GRUB 2 and the Linux kernel. This trust anchor is a vendor certificate, added to the shim binary before Microsoft signs it.

This indirection means that a Linux distribution can release bootloader and kernel updates rapidly, signing them with its own vendor key, without needing Microsoft approval for every update. Only the shim itself requires Microsoft’s signature, and it changes infrequently.

Machine Owner Key (MOK)

Machine Owner Keys (MOKs) allow a shim to use external keys managed by the user. A MOK allowlist is stored in a boot-only NVRAM variable named MokList (a shim-specific extension of the UEFI db database), and a forbidden list is stored in MokListX (the shim-specific extension of dbx). Physical access is required to modify both variables on a system with UEFI Secure Boot enabled, since boot-only variables can only be modified during boot, before the OS loader calls ExitBootServices. The shim uses the MokManager UEFI application to manage these lists.

Secure Boot Advanced Targeting (SBAT)

Each UEFI application (component) supporting SBAT carries a small piece of metadata in a dedicated .sbat section of its PE file, protected by the same signature as the binary itself. The metadata names the component (e.g., shim or grub) and assigns it a generation number that is incremented every time a security fix ships.

What turns these numbers into a revocation mechanism is a matching policy on the UEFI system itself: a boot-only UEFI variable named SbatLevel that records the minimum acceptable generation number for each known component. Crucially, this variable is managed and enforced by the shim, not the firmware, allowing faster revocation updates compared to dbx updates. The shim embeds the policy, so enforcement does not rely solely on the external variable and incorporates any newer policy provided via SbatLevel. At every boot, the shim first verifies its own SBAT metadata against the policy and then applies the same test to every binary it loads, refusing anything whose generation number falls below the minimum.

Bypassing UEFI Secure Boot Using Old Shims

Vulnerable Second-Stage Bootloaders

Each reported shim embeds both a vendor-managed and a built-in shim certificate that serve as a trust anchor for the shim’s second-stage bootloaders or utilities: GRUB 2 binaries, MokManager, fallback loaders, and occasionally other vendor-signed shims. The number of binaries trusted by a given shim varies from fewer than ten in dedicated software to close to a hundred in well-known Linux distributions.

Signing and compilation timestamps of the applications trusted by the reported shims span from 2013 to 2025—confirming that a significant portion of these binaries were old and likely affected by numerous publicly known vulnerabilities. GRUB 2 appears to be the weakest link: it is complex software, and older versions accumulate vulnerabilities accordingly.

Consider the shim from Oracle Linux, which is among those reported. It trusts binaries signed by a certificate issued to Oracle Corporation. One of the binaries signed by that certificate is a GRUB 2 binary found in the Oracle Linux 7.1 installation ISO. This binary is affected by CVE-2015-5281, which allows local users to bypass intended Secure Boot restrictions and execute non-verified code via crafted multiboot or multiboot2 modules. Both modules allow loading of unsigned code during system startup and should be forbidden in signed UEFI Secure Boot-compatible GRUB 2 binaries.

The exploit is straightforward: there are no memory corruption bugs to trigger, no ROP chains to construct, and no complex reverse engineering required. The single prerequisite is building a custom, unsigned multiboot2-compliant kernel image—little more than an ELF binary with required headers. Once an attacker builds this binary and copies it to the EFI System Partition (ESP) along with the vulnerable shim and GRUB 2, a single GRUB 2 multiboot2 command can be used to load and execute it during boot, even with Secure Boot enabled.

Absence of Newer Features

Over the years, the UEFI shim bootloader has naturally evolved with new improvements and security features. However, many third-party vendors have taken available versions of the shim source code, built their own binaries, and submitted them to Microsoft for signing without re-evaluating them against later security improvements. Insufficient attention has been given to revoking outdated Microsoft-signed shims, many of which can be leveraged to bypass newer security mechanisms by design.

MOK Denylist Enforcement

The MokList (MOK-based allowlisting) has been supported by the upstream UEFI shim since version 0.3. However, MOK revocations (MokListX) only started to be enforced in version 0.9. This creates a significant security gap:

An enterprise enrolls its own MOK to sign custom UEFI tools and bootloaders across its network. A vulnerability surfaces, and administrators revoke the old signing certificate by enrolling it into the MOK denylist (MokListX), then enroll a fresh MOK and re-sign patched versions with the new key. The old, vulnerable binaries are now rejected by up-to-date shims.

However, an attacker could replace the victim’s up-to-date shim with an older Microsoft-signed UEFI shim (e.g., version 0.8 from the Abitti 1 software). This shim still trusts the certificates stored in MokList, where the outdated MOK certificate remains valid, but it ignores MokListX entirely since it was built before MOK denylist enforcement was introduced. The attacker’s shim could then load vulnerable binaries without restriction.

SBAT Enforcement

Support for SBAT was introduced upstream in shim version 15.3, so any earlier shim is unaware of the mechanism: it does not read the SbatLevel revocation policy or inspect the .sbat section of the second-stage bootloader it loads. As a result, it ignores any later SBAT revocations intended to block vulnerable components.

An attacker could take a Microsoft-signed pre-v15.3 shim (such as version 0.9 from Red Hat Enterprise Linux 7.2), pair it with one of several GRUB 2 binaries that the shim still trusts but that SBAT has already revoked, and copy both to the ESP. During system boot, the shim validates the GRUB 2 binary against its own embedded certificate, never consults SBAT, and loads the vulnerable binary—leaving the attacker free to exploit any vulnerability in that GRUB 2 binary.

Known Shim Vulnerabilities

Old shims are simply old code, and much old code carries known vulnerabilities. A vulnerability affecting shims at version 0.9 and below was fixed and described nearly a decade ago in upstream shim commits but had no CVE ID assigned until this report. It is now tracked as CVE-2026-10797.

The issue is that an Authenticode-signed PE binary records its signature’s length in two independent locations:

• its PE header’s data directory (IMAGE_DIRECTORY_ENTRY_SECURITY), and
• its WIN_CERTIFICATE structure, which encapsulates the signature itself.

In the affected shims, the revocation check and signature verification functions diverged on which size value they should trust. The revocation check used the value from the signature header, while the signature verification function used the value from the PE header. It is thus possible to bypass the revocation mechanism by tampering with the second-stage bootloader’s WIN_CERTIFICATE structure so that the revocation function compares dbx and MokListX against bogus data instead of the bootloader’s actual signature.

Simply put, even if the second-stage bootloader’s certificate were revoked in dbx or MokListX, the shim would not find out. This bypass works only with certificate-based revocations (not hash-based ones) and requires the second-stage bootloader to be signed by a certificate embedded in the shim.

Won’t Expiring Microsoft UEFI Certificates Solve This?

With the current Microsoft UEFI certificate expirations in mind, one might wonder whether reporting vulnerable UEFI applications signed by this expired certificate is just causing unnecessary noise. However, the UEFI certificate’s expiration date has no effect on the Secure Boot verification process.

If the Microsoft Corporation UEFI CA 2011 certificate stays in db and is not revoked in dbx, all bootloaders validly signed with this expired certificate stay trusted if not explicitly revoked by hash. This is why Microsoft kept signing new submissions with the old certificate up until its expiration date.

Protection and Detection

These vulnerable shims can be blocked by applying the latest UEFI revocations from Microsoft. Windows systems should be updated automatically. The following PowerShell commands (to be run with elevated permissions) can verify whether the necessary revocations are installed:

$hashes = 
'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629'

$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
    $notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
    "All hashes revoked in dbx!"
}

For Linux systems, updates should be available through the Linux Vendor Firmware Service, and the revocation status can be checked using the uefi-dbx-audit script. For more general recommendations on protecting against exploitation of unknown vulnerable signed UEFI bootloaders and deployment of UEFI bootkits, see ESET’s blog post “Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344.”

Defensive Recommendations

• Install the latest Microsoft dbx updates immediately on all Windows systems. Check the status using the provided PowerShell commands above.
• For Linux systems, update firmware through your Linux Vendor Firmware Service to obtain the latest UEFI revocation lists.
• Use the uefi-dbx-audit script on Linux systems to verify that vulnerable shim binaries have been revoked.
• Ensure UEFI Secure Boot is enabled on all systems to benefit from revocation mechanisms (Windows 11 Secured-core PCs should have this enabled).
• Disable Microsoft Corporation UEFI CA 2011 enrollment on systems if you have disabled third-party UEFI signing for security purposes.
• Monitor firmware updates and SBAT policy changes in your environment, as these provide efficient version-based revocation for future vulnerabilities.
• For enterprise environments, consider restricting UEFI modifications through firmware settings and group policies to prevent unauthorized bootloader installation.
• Audit systems for unexpected UEFI bootloaders or shim binaries during security assessments.

Conclusion

What makes these old shims dangerous is not a novel vulnerability—it’s that no new vulnerability is needed to bypass UEFI Secure Boot. An attacker needs 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.

While revoking these 11 shims addressed the immediate issue, a deeper problem remains: visibility. The shim signing process became significantly more transparent in 2017 with the introduction of the shim-review repository, where vendor submissions are vetted by maintainers before Microsoft signs them. Every shim approved since then is documented—but those signed earlier are not, and no one can reliably say how many old, still-trusted shims remain. What has not been fully and transparently catalogued cannot be effectively retired.

On a positive note, the trend is moving in the right direction. Each disclosure like this shrinks the pool of forgotten shims, and with improved shim-signing transparency and mechanisms such as SBAT, tracking what needs revocation and effectively revoking it can be handled far more efficiently than before. The next step is extending this transparency in Microsoft’s third-party UEFI signing ecosystem to non-shim third-party UEFI applications, which have repeatedly served as a straightforward source of UEFI Secure Boot bypasses.

Original text: “Forgotten UEFI shims undermining Secure Boot” by Martin Smolár at ESET Research.