Microsoft revoked 11 signed UEFI boot files this summer that had let attackers walk straight past Secure Boot since as far back as 2013. Security firm ESET found the shims still valid, still trusted, and still sitting quietly on machines nobody thought to check.
The fix closes those 11 specific files. It does not explain why a public, well-documented bypass sat untouched for over a decade, or how many more forgotten shims like them are still floating around, unrevoked.
Eleven Old Files, One Very Long Blind Spot
ESET researchers identified 11 old UEFI shim bootloaders, all at version 0.9 or earlier, signed under Microsoft’s “Microsoft Corporation UEFI CA 2011” certificate. Any machine that trusts that certificate accepts them, Windows or Linux, no matter what software is actually installed on it.
Martin Smolár, the ESET researcher who led the work, documented 11 forgotten shim bootloaders capable of bypassing UEFI Secure Boot regardless of the operating system installed. The case is tracked under two identifiers, CVE-2026-8863 and CVE-2026-10797, and the first carries a CVSS v3.1 base score of 7.8, a high severity rating. Pulling it off can hand an attacker a foothold for known UEFI bootkits such as Bootkitty, HybridPetya, or BlackLotus, malware families ESET has tracked before that run before Windows, before any antivirus, before anything capable of noticing them.
“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.” He said an attacker needs nothing more than “a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims work.”
The Workaround That Let Linux Boot Under Windows Rules
Secure Boot arrived in 2012 to keep unsigned code out of a computer’s startup sequence. Every piece of software in the chain needs a trusted signature, and Microsoft holds the master key nearly every PC ships with.
Linux distributions cannot submit a new bootloader to Microsoft every time they patch something, so the shim exists as a middleman. It is a small program Microsoft signs once, which then vouches for the next stage of the boot process, usually GRUB 2, using its own separate certificate list.
GRUB 2 tends to be the weakest link in that chain, according to ESET, since it is complex enough that older versions simply pile up known flaws over time.
That setup only holds if a vulnerable shim gets revoked the moment its flaws surface. In these 11 cases, nobody flagged them in time. Some predate the Machine Owner Key denylist, added in shim version 0.9. Others predate Secure Boot Advanced Targeting, or SBAT, a version-based revocation system that only shipped in version 15.3. An old enough shim simply never checks either list.
Why the Fix Took Four Months
Closing the gap took four months from ESET’s initial report to a working patch. ESET reported its findings to the CERT Coordination Center in mid-February. Microsoft first set a revocation date in May, then pushed it back to June 9 to give affected vendors time to ship replacement shims before the old ones stopped working.
The June 9 Patch Tuesday update added all 11 shim hashes to the UEFI forbidden signature database, known as dbx. The same fix shipped again in July’s cumulative update, KB5101650, for anyone who had skipped a month. Windows machines generally pull the revocation automatically.
The certificate that signed all 11 files, Microsoft Corporation UEFI CA 2011, expired on its own on June 27, timed close to Microsoft’s broader rollout of refreshed Secure Boot certificates. Expiration alone changes nothing for Secure Boot verification, though. A shim signed under an expired certificate still boots fine unless its exact hash has been explicitly blocked. That single certificate has signed thousands of third-party boot files over more than a decade, by one estimate.
Which Machines Are Actually At Risk?
Any UEFI-based computer trusting the Microsoft Corporation UEFI CA 2011 certificate was exposed, which ESET says covers the vast majority of Windows and Linux machines built over the past decade, regardless of what software they actually run. Windows 11 Secured-core PCs are the exception, since they turn off third-party UEFI signing by default.
The “bring your own shim” part is what makes this different from an ordinary software bug. An attacker does not need the vulnerable program installed already. They just need to drop one of the 11 old files onto a USB drive or a machine’s EFI System Partition, alongside a matching old GRUB 2 build, and Secure Boot waves it through.
Motherboard makers AMI and Gigabyte both told CERT/CC their BIOS builds do not bundle the flagged shim files directly. Machines built on their boards can still load one of the 11 files if it arrives from outside, such as on a USB drive.
The 11 flagged shims trace back to a mix of vendors:
- Red Hat and CentOS – Enterprise Linux 7.2 install media shipped with one of the flagged shim versions.
- Oracle Linux – its shim trusted a GRUB 2 binary from the 7.1 installation ISO vulnerable to CVE-2015-5281, a flaw ESET says takes relatively little skill to exploit.
- PC-Doctor Service Center – diagnostic software versions 15 and 16 carried the same outdated 0.9 shim.
- Spyrus WTGCreator – a Windows-to-go creation tool signed with shim version 0.7 or older.
- openSUSE, Baramundi, WhiteCanyon WipeDrive, and Finland’s Abitti exam platform – each carried its own unrevoked, Microsoft-signed shim.
Windows users who installed June’s or July’s cumulative update are already protected. Linux users can pull the same revocation through the Linux Vendor Firmware Service.
Secure Boot Has Cracked Before
This is not the first time the boot chain’s revocation lists have buckled under their own weight. The BootHole disclosure in 2020, tracked as CVE-2020-10713, forced Microsoft to add three certificates and 150 image hashes to dbx in one go, using up roughly a third of the 32KB of revocation storage most UEFI platforms carry.
Later cleanup tied to the BlackLotus bootkit pushed the merged dbx list toward roughly half of that capacity. Both episodes are why Microsoft and its partners built SBAT, plus a similar Secure Boot SVN system for Windows Boot Manager: version-based rules that can block whole ranges of vulnerable code without needing a hash for every single file.
| Incident | Root Cause | Effect on the Revocation Database |
|---|---|---|
| BootHole (2020) | CVE-2020-10713, a GRUB 2 parsing flaw | 3 certificates and 150 image hashes added to dbx, about a third of the 32KB store |
| BlackLotus cleanup | Vulnerable Windows Boot Manager binaries | Combined dbx entries pushed close to half of total capacity |
| Forgotten shims (2026) | CVE-2026-8863 and CVE-2026-10797 | 11 shim hashes added in the June 9 Patch Tuesday update, four months after ESET’s report |
The pattern has a parallel outside the PC world, too. An unpatchable flaw in Apple’s iPhone BootROM showed the same root-of-trust problem playing out in hardware that can never be patched, only mitigated around.
The Ecosystem Nobody Can Fully Inventory
The shim-review process, where vendor submissions get vetted before Microsoft signs them, only began in 2017. Anything signed before that has no guaranteed public record, and ESET says it cannot say with confidence how many more old, still-trusted shims remain in circulation.
HD Moore, CEO and founder of the network discovery firm runZero, called the discovery a rebuke of the entire model behind Secure Boot. Moore said the situation leaves “a huge number of unknown (to everyone but Microsoft) signed things that bypass Secure Boot,” many of which can then boot still other components, some carrying their own bugs that let them boot nearly anything.
The whole ecosystem is somewhat broken and needs a reboot.
HD Moore, CEO and founder of runZero, said in an interview.
Patch Tuesday itself keeps growing more complex to manage. The same monthly cycle has separately swollen to a reported 570 flaws in one release, part of Microsoft’s AI-assisted bug hunting push, adding to the pile any administrator already has to track. Smolár’s own fix for the deeper problem points the same direction as Moore’s complaint: extend the shim-signing transparency built since 2017 to the rest of Microsoft’s third-party UEFI signing program, since non-shim boot applications have produced their own Secure Boot bypasses before, including CVE-2022-34302, CVE-2023-28005, and CVE-2024-7344.
Frequently Asked Questions
What Does a UEFI Shim Actually Do?
A shim is a small, Microsoft-signed program that sits between a computer’s firmware and its main bootloader, typically GRUB 2 on Linux. It carries its own separate trust list, stored in NVRAM variables called MokList and MokListX, and a tool called MokManager lets administrators manage which keys that list trusts.
How Do I Check If My Windows PC Still Has a Vulnerable Shim?
ESET published PowerShell commands, meant to run with elevated permissions, that check whether any of the 11 revoked hashes are still present in a system’s dbx list. Anyone who has installed the June or July cumulative update should already be clear.
How Do Linux Users Confirm They Are Protected?
Linux systems pull the same dbx revocation through the Linux Vendor Firmware Service, and a script called uefi-dbx-audit can confirm whether the update actually landed. Distribution maintainers are the fastest way to check on machines that do not run LVFS by default.
Was This Bug Ever Used in a Real Attack?
No evidence has surfaced of the flaws being exploited before ESET’s disclosure. That does not rule out quiet use going forward, since any of the 11 shims can still be carried in on a USB drive by anyone who never applies the revocation.
Does Updating the Certificate Database Risk Breaking a PC?
Yes, if it is done in the wrong order. CERT/CC’s advisory tracking the case as VU#616257 says to update the authorized signature database, known as db, before applying the dbx revocations. Reversing that sequence can leave a machine unable to boot at all.
