No one knows how many old shims can still bypass UEFI Secure Boot

The vast majority of UEFI computers carry a Microsoft certificate that will trust a small first-stage loader called a shim, a program Microsoft signs so that Linux and assorted boot tools can run with Secure Boot on. Eleven of those signed shims turned out to be old enough to undo the protection they were meant to support. ESET researchers found the vulnerable versions, all at 0.9 or below, and Microsoft revoked them in its June 9, 2026 Patch Tuesday update.

One certificate, many machines

The affected shims are trusted by any UEFI system that carries Microsoft’s third-party certificate, the Microsoft Corporation UEFI CA 2011, and they behave the same way regardless of the operating system. An attacker copies one of these old shims onto a target machine with a matching second-stage loader, and the boot chain accepts it. Exploitation reaches systems that never shipped the vulnerable software, because the attacker supplies the binary. Two identifiers cover the case, CVE-2026-8863 and CVE-2026-10797.

A shim solves a signing problem: it is a minimal loader that Microsoft vets and signs one time, and it then vouches for the next stage, usually GRUB 2, using a vendor certificate baked in. GRUB 2 in turn verifies the Linux kernel against that same certificate.

Simplified UEFI boot flow on Linux systems (Source: ESET)

The weak second stage

The danger grows through those second-stage loaders. A single shim can trust anywhere from fewer than ten binaries to close to a hundred in a major Linux distribution. The signing timestamps run from 2013 to 2025, and many of the older ones carry publicly known bugs. GRUB 2 is the weakest component, large and gathering flaws as versions age.

One reported Oracle Linux shim trusts a GRUB 2 binary from the Oracle Linux 7.1 installation media that is vulnerable to CVE-2015-5281, a flaw that, in the words of the vulnerability note, occurs “when used on UEFI systems, allows local users to bypass intended Secure Boot restrictions and execute non-verified code via a crafted (1) multiboot or (2) multiboot2 module”. The attack takes little effort: an attacker builds an unsigned multiboot2 kernel image, copies it to the EFI System Partition with the old shim and GRUB 2, and loads it with one command at boot.

Missing protections

Old shims also lack security features added to the shim project after they were built. MOK denylist enforcement, which lets a system reject a revoked Machine Owner Key, arrived only in version 0.9. Support for Secure Boot Advanced Targeting, or SBAT, arrived in version 15.3. A shim built before those points ignores the matching revocations. An attacker can swap a patched shim for an older Microsoft-signed one, such as a version 0.8 shim from Finland’s Matriculation Examination Board exam software, and it loads binaries that current policy already blocks.

A separate flaw, now tracked as CVE-2026-10797, was fixed upstream almost a decade ago and went without a CVE ID until this report, and the old signed shims that carry it were never revoked. A signed PE binary records its signature length in two places, and the affected shims read one location during the revocation check and the other during signature verification. Tampering with the WIN_CERTIFICATE structure of a second-stage loader steers the revocation check toward the wrong bytes, so a certificate revoked in dbx or MokListX slips past. The bypass works only on certificate-based revocations, where the second-stage loader is signed by a certificate embedded in the shim. Hash-based revocations still hold.

Applying the fix

Certificate expiration offers no relief here. The Microsoft UEFI CA 2011 certificate expired on June 27, 2026, and that date has no effect on Secure Boot verification. A bootloader signed by it stays trusted for as long as the certificate remains in db and its hash stays out of dbx. Microsoft signed submissions with it until that date.

Blocking these shims comes down to applying the current UEFI revocations. Windows machines receive the dbx update automatically, and ESET published PowerShell commands, to be run with elevated permissions, that check whether the eleven revoked hashes are present. Linux systems can pull the update through the Linux Vendor Firmware Service and confirm the result with the uefi-dbx-audit script. Windows 11 Secured-core PCs should have third-party signing off by default.

The shim-review repository, started in 2017, documents every shim submitted for signing since then, and no comparable record exists for the ones signed earlier. No one can say with confidence how many old, still-trusted shims remain. Revoking these eleven shrinks that pool, and version-based revocation such as SBAT makes the next cleanup faster. The same record-keeping now needs to reach third-party UEFI applications beyond shims, which have supplied Secure Boot bypasses of their own.

Download: The ultimate guide to network operations management