Attackers could bypass UEFI Secure Boot on a wide range of systems thanks to 11 Microsoft-signed UEFI shim bootloaders carrying vulnerabilities that have remained buried for more than a decade, according to new findings from ESET.
ESET researchers reported the shims to the CERT Coordination Center (CERT/CC) in February 2026. All are versions 0.9 or below and were signed under Microsoft’s Microsoft Corporation UEFI CA 2011 third-party certificate, meaning any UEFI system that trusts that certificate will accept them regardless of the installed operating system.
Exploitation allows untrusted code to run during boot, opening the door to UEFI bootkits such as Bootkitty, HybridPetya and BlackLotus, even with Secure Boot switched on.
Old Code, No Exploit Needed
A shim is a small first-stage bootloader that Microsoft signs once, this allows Linux distributions boot under Secure Boot without submitting every update for signing. Crucially, an attacker can bring a vulnerable shim to any system carrying the Microsoft third-party certificate and boot from it.
The danger is less about any single bug than the outdated second-stage bootloaders each shim still trusts, mostly GRUB 2. Signing timestamps of the trusted binaries span 2013 to 2025, and older GRUB 2 builds carry well-documented flaws.
ESET demonstrated this with the shim from Oracle Linux, which trusts a GRUB 2 binary vulnerable to a 2015 flaw allowing unsigned code to load via crafted multiboot modules.
The attack needs no memory corruption or reverse engineering. It is enough for an attacker to build an unsigned kernel image, copy it alongside the old shim and GRUB 2 and load it with a single command at boot.
Bypassing the Newer Defenses
The shims also sidestep mechanisms built to catch this. Enforcement of the Machine Owner Key (MOK) denylist only arrived in version 0.9, so older shims ignore it, allowing an attacker to load binaries that an organization believed had been revoked.
The same gap applies to Secure Boot Advanced Targeting (SBAT), the version-based revocation system introduced in shim 15.3: earlier shims never check the SBAT policy.
The deeper problem is visibility, ESET warned. Shim submissions have been cataloged transparently only since 2017, and no one can say how many older, still-trusted shims remain in circulation.
Two CVE IDs, CVE-2026-8863 and CVE-2026-10797, cover the reported shims, and Microsoft revoked the vulnerable binaries in the dbx update shipped with its June 9 Patch Tuesday.
Read more on these fixes: Microsoft Fixes 200 CVEs in June Patch Tuesday
Windows machines should update automatically, while Linux users can pull the revocation through the Linux Vendor Firmware Service.
“As the vulnerable shims are part of legitimate software packages that are potentially present on thousands of systems that have never been compromised via these loaders, we are not providing indicators of compromise to avoid massive misidentification,” ESET clarified.
“Instead, defenders should follow the advice in the Protection and detection section.”
