The Discovery: A Decade-Old Hole in Secure Boot
Eleven Microsoft-signed UEFI shim bootloaders are carrying vulnerabilities that let attackers completely bypass Secure Boot. That’s the takeaway from a new ESET report, and the flaws have been sitting there for more than ten years.
These aren’t exotic, hard-to-reach bugs. No memory corruption. No reverse engineering. Just old code that still trusts even older code.
ESET flagged the shims to CERT/CC back in February 2026. All of them are version 0.9 or below, signed under Microsoft’s Microsoft Corporation UEFI CA 2011 third-party certificate. That’s the catch — any system that trusts that certificate will accept these bootloaders, no matter the OS installed.
Why Shims Exist (And Why They’re Dangerous)
A shim is a tiny first-stage bootloader. Microsoft signs it once, and that signature lets Linux distributions boot under Secure Boot without submitting every single update for signing. Convenient, sure. But it also means an attacker can grab a vulnerable shim, carry it to any machine with the Microsoft third-party cert, and boot from it.
The real problem isn’t the shim itself. It’s the second-stage bootloaders these old shims still trust — mostly GRUB 2. The trusted binaries were signed between 2013 and 2025, and older GRUB 2 builds are riddled with well-known flaws.
ESET proved the point using Oracle Linux’s shim. It trusts a GRUB 2 binary vulnerable to a 2015 bug that lets unsigned code load through crafted multiboot modules. The attack is almost trivial: build an unsigned kernel image, drop it next to the old shim and GRUB 2, and load it with a single command at boot.
Bypassing the Defenses Built to Catch This
The shims also sidestep the very mechanisms designed to stop them.
- MOK denylist: Enforcement only arrived in shim version 0.9. Older shims ignore it entirely, so an attacker can load binaries that an organization thought were revoked.
- Secure Boot Advanced Targeting (SBAT): This version-based revocation system came in shim 15.3. Earlier shims never even check the SBAT policy.
That’s a double whammy. Even if you’ve revoked a malicious bootloader, these old shims won’t respect your decision.
The deeper issue is visibility. Shim submissions have only been cataloged transparently since 2017. Nobody knows how many older, still-trusted shims are out there. That’s a scary thought for anyone managing a fleet of Linux servers.
What’s Been Fixed (And What Hasn’t)
Two CVEs cover the reported shims: CVE-2026-8863 and CVE-2026-10797. Microsoft revoked the vulnerable binaries in the dbx update shipped with its June 9 Patch Tuesday.
Windows machines should update automatically. Linux users can pull the revocation through the Linux Vendor Firmware Service.
But here’s the kicker: ESET isn’t releasing indicators of compromise. The vulnerable shims are part of legitimate software packages on thousands of systems that have never been compromised. Releasing IoCs would cause massive misidentification.
Instead, defenders should follow the advice in ESET’s Protection and detection section. That’s the practical path forward.
What This Means for Your Systems
If you’re running Linux on UEFI hardware, this is worth taking seriously. The attack doesn’t need physical access — an attacker just needs to boot from a USB drive or compromise the boot chain.
Check your shim version. If it’s 0.9 or below, you’re exposed. Update through your distribution’s normal channels, and make sure the dbx update is applied.
For security teams, this is a reminder that Secure Boot isn’t a silver bullet. It’s a chain, and every link matters. Old shims are a weak link that’s been hiding in plain sight for a decade.
Related reading: Microsoft fixes 200 CVEs in June Patch Tuesday and how to check your Linux bootloader version.
