Every modern PC ships with Secure Boot enabled — a firmware-level defense, active since roughly 2012, designed to stop bootkits from hijacking your machine before the operating system even loads. It was supposed to be the bouncer at the door. Turns out that bouncer has been waving people in from a guest list nobody updated for over a decade.
ESET researcher Martin Smolár found 11 UEFI “shim” bootloaders, some dating to 2013, still signed and trusted by Microsoft’s third-party certificate authority. No clever zero-day required. Just old files, publicly available, that Secure Boot still treats like VIPs.
The Skeleton Key Nobody Revoked
Old Linux bootloaders, still Microsoft-signed, let attackers slip past firmware security with embarrassing ease.
Shims are small bootloaders that allow Linux distributions — Red Hat, openSUSE, and Oracle, among others — to participate in Secure Boot’s chain of trust. The attack is painfully straightforward: grab one of these ancient, still-trusted binaries, use it to load malicious boot code before your OS starts, and install a surveillance app that survives reinstalls and drive swaps alike.
“No new vulnerability is needed to bypass UEFI Secure Boot… only a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims work,” Smolár said, per welivesecurity.com. One Oracle shim still authorizes a binary vulnerable to a flaw from 2015 — which Smolár classifies as low-skill to exploit.
- CERT/CC tracks the issue as VU#616257, covering CVE-2026-8863 and CVE-2026-10797
- Affected vendors include Red Hat, openSUSE, Oracle, and third-party utility makers
- Microsoft shipped revocations in the June 9, 2026 Patch Tuesday DBX update
- Linux users must separately confirm revocations via LVFS firmware updates
- Windows 11 Secured-core PCs, with third-party signing disabled by default, were largely unexposed
The revocation database (DBX) is capped at roughly 32KB — too small to blacklist every vulnerable binary by individual hash. Microsoft built SBAT as a scalable fix, revoking components by version number rather than file-by-file. These 11 shims either predate SBAT entirely or contain bugs that prevent it from working. Think of it as a nightclub that upgraded its ID scanners but never collected the old master keys.
The Patch Exists. The Problem Doesn’t End.
Microsoft revoked 11 documented shims, but no one knows how many untracked legacy binaries are still out there.
HD Moore, CEO of runZero, put it bluntly: “This is a solid rebuke of the entire secure boot model… The whole ecosystem is somewhat broken and needs a reboot,” per Ars Technica. Some analysts frame this as a fixable process failure — better revocation hygiene, more rigorous SBAT enforcement — but Moore’s position is that centralizing trust in a single authority is itself the structural flaw.
Before 2017, no central repository tracked signed shims. An unknown number of pre-2017 binaries remain unaccounted for, turning remediation into perpetual whack-a-mole. Worth noting: the expiration of Microsoft’s UEFI CA 2011 certificate in late June 2026 does not automatically revoke these binaries. Explicit DBX blacklisting is required — and that only covers the shims someone has already found.
Security features can fail silently for years — not because attackers outsmarted anyone, but because nobody checked the inventory. If you’re on Windows, verify your June 2026 Patch Tuesday update is applied. Linux users: check LVFS for firmware updates now.
