Eleven UEFI shim bootloaders, all carrying a valid Microsoft signature, have quietly undermined Secure Boot for years. ESET researcher Martin Smolár found the flaws and reported them to CERT/CC in February. He disclosed the full technical detail this week, after Microsoft revoked the vulnerable binaries. The case is now tracked as VU#616257, covering CVE-2026-8863 and CVE-2026-10797. This UEFI Secure Boot bypass matters because it needed no new exploit code at all.
What the shims actually do
A shim is a tiny first-stage bootloader. Its job is simple: hold a Microsoft certificate, verify the next boot component, usually GRUB 2, and hand off control. Microsoft signs most third-party shims under its UEFI CA. Any PC that trusts Microsoft’s certificate trusts every shim Microsoft has signed, unless that specific shim has since been revoked.
That is where the trouble starts. Smolár’s research, published on WeLiveSecurity, identifies 11 shims at version 0.9 or earlier. They come from products including Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, openSUSE, Baramundi Management Suite, WhiteCanyon WipeDrive and Finland’s Abitti exam software. None of them were updated after the shim project shipped later security fixes.
Three ways in, no new bugs required
This UEFI Secure Boot bypass works through three distinct failures in the affected shims. Each weakness was already known and simply never patched in these specific builds. First, several still trust old GRUB 2 binaries vulnerable to CVE-2015-5281, a 2015-era flaw. It lets an attacker load unsigned code through GRUB’s multiboot command, walking straight past Secure Boot.
Second, shims built before version 15.3 never implemented SBAT. SBAT lets vendors revoke specific vulnerable component versions without pulling an entire certificate. Without it, a shim has no way to know a component it trusts has since been blacklisted.
Third, and newly assigned as CVE-2026-10797, shims below 0.9 read a signed binary’s certificate length from the wrong place. A signed executable records its signature size in two locations: the PE header and the WIN_CERTIFICATE structure. The vulnerable shims check revocation against one value, but verify the signature against the other. That mismatch lets an attacker tamper with the certificate structure and slip a malicious binary past the check.
Why the UEFI Secure Boot bypass reaches beyond 11 products
Secure Boot validates a shim’s signature, not the machine it shipped on. So an attacker does not need a victim running Red Hat 7.2 or WipeDrive. Any of the 11 vulnerable shims can be copied onto a USB drive, or dropped into a Windows machine’s EFI partition. That works so long as the machine trusts Microsoft’s third-party UEFI certificate. Almost all of them do, by default. From there, the shim becomes a launchpad for bootkits such as Bootkitty, HybridPetya or BlackLotus. All three run before antivirus, EDR or the operating system itself has loaded. The same trust-first assumption let a recent Arch Linux supply-chain compromise plant an eBPF rootkit that hid from standard inspection tools once it was running.
“What makes these old shims dangerous is not a novel vulnerability,” Smolár wrote, “it’s that no new vulnerability is needed to bypass UEFI Secure Boot.” That line is the real headline here: every individual weakness was already public. What was missing was someone cataloguing which specific signed binaries still carried them forward.
The fix, and why it took four months
Closing this UEFI Secure Boot bypass took four months from disclosure to fix. ESET reported the findings to CERT/CC on 16 February 2026. Microsoft initially set a revocation date of 19 May. It pushed that back to 9 June. That gave affected vendors time to ship replacement shims before the old ones were blocked entirely. The June Patch Tuesday update pushed the DBX, the UEFI forbidden-signature database, to Windows machines. That blocked all 11 shim binaries from loading during boot.
Revocation by hash, not by certificate expiry, was the only option. The shims’ signing certificate, Microsoft Corporation UEFI CA 2011, expired on its own in late June. But that alone protects nothing. An attacker with an old copy of a vulnerable shim can still present it during boot, unless its specific signature has been explicitly blocked. CERT/CC’s advisory flags one more ordering issue: update DB, the authorised signature database, before applying DBX revocations. Do it the other way round, and affected machines can be left unable to boot at all.
Where things stand
No evidence has surfaced of the flaws being exploited before disclosure. Help Net Security reports that ESET itself cannot say how many forgotten shims remain undiscovered. The certificate has signed thousands of third-party binaries over more than a decade. This UEFI Secure Boot bypass is not fully closed everywhere yet. Administrators who have not applied June’s cumulative update should treat it as unfinished business, not a closed case. So should anyone managing air-gapped or legacy systems that skip routine DBX pushes. It also isn’t the only recent case of a device’s root of trust turning out softer than advertised. The usbliter8 exploit against Apple’s SecureROM showed the same problem playing out in hardware. That hardware can never be patched, only mitigated around.