ESET: 11 old signed UEFI shims still bypass Secure Boot

The Secure Boot trust chain is straightforward on paper. Firmware verifies the shim’s signature against a Microsoft-controlled certificate. Shim verifies the second-stage bootloader — GRUB, most commonly. GRUB verifies the kernel. The kernel goes on to do the rest. Every link is signed, every link is checked, and the property everyone in the chain assumes is that a Microsoft-signed shim will remain a Microsoft-signed shim.

That property has a shelf life. It ends when the specific binary in question is added to the DBX — the on-firmware revocation list — and not before. Until then, firmware will happily load any shim carrying a valid signature from Microsoft’s UEFI Certificate Authority, including a shim from 2015 that has been sitting in a package archive on the internet the entire time.

ESET’s Martin Smolár published on 2026-07-14 the results of an audit against exactly that question: how many old, Microsoft-signed shim binaries are still out there, still trusted, and still vulnerable enough that an attacker who can swap them in during the boot process gets to run code before the operating system does. The answer was eleven, tracked as CVE-2026-8863 and rated 7.8 on the NVD entry that appeared on 2026-06-09. CERT/CC’s VU#616257 carries the same finding.

The eleven

Per ESET’s writeup, in shim version order:

• shim 0.7 — Spyrus WTGCreator; WhiteCanyon/Blancco WipeDrive 8.0.0–8.1.3.
• shim 0.8 — Baramundi Management Suite up to 2024R1; Finland Matriculation Board Abitti 1.0.
• shim 0.9 — RHEL 7.2; CentOS 7.2; Oracle Linux 7.2; NTC IT ROSA Linux R9 and R10; PC-Doctor Service Center 15 and 16; OpenSUSE UEFI Shim loader 0.9; OpenSUSE Shim 2.1.

None of those distributions are current. RHEL 7.2 shipped in 2015; CentOS 7.2 mirrored it; Oracle Linux 7.2 the same. That is what makes the finding interesting rather than routine. The bugs those specific shim releases contained — path-traversal in the second-stage loader, MOK-list mishandling, and similar — were patched years ago at the upstream project (rhboot/shim, commit history available on GitHub). What was never done, until June, was to revoke the still-signed binaries themselves. The fix upstream, in other words, does not follow the binary. The binary keeps traveling with the same Microsoft signature it left the factory with, and firmware — which has no concept of “this shim was patched five years ago, refuse to load an older one” — keeps trusting it.

The class of bypass is old enough to have its own LogoFAIL-adjacent literature at this point, and the mechanic ESET describes is the general one: a locally-privileged attacker replaces the shim on disk with a still-signed older shim, that older shim loads without a signature complaint, and its known bug — the one long since fixed upstream — is used to load a second-stage bootloader that firmware would otherwise refuse. From there, a UEFI bootkit lives above the OS’s ability to see it. ESET’s own summary of the required attacker capability: “no complicated exploitation primitives — only a copy of an old, still-trusted, but unrevoked shim binary.” We are not going to reproduce the reversing steps; the ESET blog and the CERT note have the depth for readers who need it.

Why local admin still matters here

Two things are worth registering about the “requires local administrative privileges” framing, because it will show up in every summary of this and it does not mean what it looks like.

First, the population that has local admin on Secure Boot–enabled endpoints is not small. It includes every helpdesk technician doing warranty imaging, every red-team consultant with a signed engagement, every stolen-laptop chain-of-custody gap, and — this is the load-bearing one — any prior malware that has already achieved SYSTEM or root. A persistence primitive that promotes an existing local compromise into pre-OS persistence, resistant to reimaging and invisible to endpoint detection running above the kernel, is worth substantially more to an attacker than the initial compromise it required. That is the shape of a bootkit implant, and the reason UEFI research keeps finding an audience.

Second, the physical layer of the trust chain — the part firmware actually reads — is the DBX. If the DBX in a given machine’s firmware does not carry the June 2026 revocation entries, then that machine’s Secure Boot is, on this specific vector, no more discriminating today than it was five years ago. Applying the June Windows Patch Tuesday update, or the equivalent Linux fwupd / LVFS refresh, is what actually lands the DBX changes on firmware. OS-level patches alone don’t.

What to actually do

• On Linux endpoints and servers: confirm the June 2026 DBX update reached firmware. mokutil --list-new will show pending revocations; fwupdmgr get-updates will show whether a firmware-side DBX package is available and unapplied. Many enterprise fleets patch the OS reliably and never push firmware updates; this is the population most exposed here.
• On Windows: the DBX revocation ships as part of the June 2026 MSRC advisory for CVE-2026-8863. Verify via Get-SecureBootUEFI db / Get-SecureBootUEFI dbx in an elevated PowerShell, comparing the returned bytes against Microsoft’s published dbxupdate manifest.
• On appliances and old-hardware fleets: the Spyrus, Blancco WipeDrive, PC-Doctor, and Baramundi entries in the affected list all target device populations that see less patching attention than general-purpose servers. Wiping stations, warranty-repair rigs, and older management endpoints are the fleets most likely to still be running one of the eleven shims. Vendor firmware updates from those vendors, not from Microsoft, are what applies here.
• Detection: ESET’s IoCs — hashes of the eleven affected binaries — are in the WeLiveSecurity post. File-integrity monitoring for \EFI\ paths across the fleet is the concrete check.

The Microsoft Corporation UEFI CA 2011 certificate itself expired on 2026-06-27, and the replacements — Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 — are the ones going forward. That is a separate development from this finding and does not, by itself, do anything about already-signed old binaries. Expiry stops new signings. Revocation removes existing ones. The DBX update is the revocation.

Related coverage

• 11 old Microsoft-signed Linux UEFI shims could bypass Secure Boot — The Hacker News summary of the ESET writeup.
• Forgotten UEFI shims undermining Secure Boot — ESET Research, the primary source.
• SAP’s July Patch Day: three criticals, worst is 9.9 — the day’s other significant vendor release.

Sourcing

• ESET Research. Forgotten UEFI shims undermining Secure Boot, 2026-07-14.
• The Hacker News. 11 Old Microsoft-Signed Linux UEFI Shims Could Let Attackers Bypass Secure Boot, 2026-07-14.
• NVD. CVE-2026-8863, 2026-06-09.
• CERT/CC. VU#616257.
• MSRC. Advisory for CVE-2026-8863.