11 Old Microsoft-Signed UEFI Shims Left Secure Boot Bypassable for 13 Years
ESET found that 11 old UEFI shim bootloaders, still validly signed under Microsoft's third-party CA, let attackers bypass Secure Boot on any UEFI machine that trusts that certificate — no exploit development required.
Key Takeaways
- ESET found 11 Microsoft-signed UEFI shim bootloaders (version 0.9 and below) that bypass Secure Boot on any UEFI system trusting Microsoft's 2011 third-party CA, regardless of installed OS.
- The flaw isn't a crypto break — it's a trust-management failure: Microsoft kept the shims' signatures valid for years after the underlying GRUB 2 flaws (e.g. CVE-2015-5281) were public and patched.
- Exploitation needs only access to the EFI System Partition and a copy of one vulnerable binary — no exploit development, no reverse engineering, and no need to have the vulnerable software actually installed.
- Microsoft revoked the flagged shims on the June 2026 Patch Tuesday (CVE-2026-8863, CVE-2026-10797, tracked as CERT/CC VU#616257); ESET says the 11 found are not exhaustive.
For most of its 14-year life, Microsoft's Secure Boot has carried a soft spot that required no cryptographic breakthrough to exploit — just patience. ESET researcher Martin Smolár found that 11 old UEFI shim bootloaders, versions 0.9 and below, are still validly signed under Microsoft's Microsoft Corporation UEFI CA 2011 certificate — the trust anchor most OEMs enroll so Linux and other third-party boot software can run on Secure Boot-enabled hardware. One shim's compilation timestamp dates back to 2013.
How a signed shim becomes a bypass
Shims exist to bridge Microsoft's UEFI CA and second-stage bootloaders — usually GRUB 2 — that Microsoft doesn't sign directly. The vulnerable versions still trust old, since-patched flaws in that second stage. ESET points to CVE-2015-5281 as one concrete path: a crafted multiboot or multiboot2 module lets GRUB 2 load unverified code. An attacker only needs to place one of the 11 vulnerable binaries, plus a matching unsigned kernel image, on the EFI System Partition.
- Requires only access to the EFI System Partition — physical, remote admin, or supply-chain — not a novel exploit
- Works regardless of the installed OS, since the certificate trust is system-wide, not tied to a specific distro or app
- Delivers code execution before the OS or any endpoint agent loads, which is what makes it attractive for persistent UEFI bootkits
Why it sat unpatched for over a decade
The underlying GRUB flaws were public and fixed in GRUB 2 itself years ago. What didn't happen was revocation: Microsoft kept trusting the old shim binaries instead of pulling their certificates, so any system that never updated GRUB — or that simply had one of these binaries copied onto its EFI partition — stayed bootable and exploitable. Pushing UEFI revocation lists (dbx) at scale is notoriously risky, since an aggressive revocation can brick dual-boot or recovery configurations, which is a plausible reason the gap persisted this long.
What changed, and what's still open
Microsoft revoked the 11 flagged shims in its June 2026 Patch Tuesday update. The issue is tracked by CERT/CC as VU#616257 under CVE-2026-8863 and CVE-2026-10797. ESET is explicit that its list of 11 is a sample, not a census — the shim ecosystem contains far more third-party binaries than were checked, and no one currently has a complete inventory of which are similarly stale.
What security teams should do
- Confirm that
dbxrevocation updates covering the June 2026 shim entries have actually reached device firmware, not just the OS patch layer - Inventory EFI System Partitions across the fleet — especially dual-boot, recovery, and imaging hosts — for old or duplicate shim/GRUB binaries
- Treat Secure Boot as one layer, not a guarantee: pair it with boot-integrity attestation and monitoring that has visibility into pre-OS activity where feasible
- Track CERT/CC VU#616257, since more vulnerable shims beyond ESET's initial 11 are plausible
Frequently Asked Questions
What is a UEFI shim, and why does Secure Boot need one?
A shim is a small, Microsoft-signed bootloader that bridges Microsoft's Secure Boot trust chain to second-stage bootloaders like GRUB 2 that Microsoft doesn't sign directly, allowing Linux and other non-Windows software to boot on Secure Boot-enabled hardware.
Does this mean Secure Boot itself is cryptographically broken?
No — the signature verification still works correctly. The problem is that Microsoft kept trusting shim binaries whose second-stage bootloaders had known, years-old vulnerabilities instead of revoking them, so a valid signature ends up authorizing code that shouldn't be trusted.
Do I need to run Linux to be affected by this?
No. Because the trust lives in the shared Microsoft Corporation UEFI CA 2011 certificate, any UEFI system that enrolls that CA — including Windows-only machines — can be targeted if an attacker gets one of the 11 vulnerable binaries onto the EFI System Partition.
Sources
- 1Long-Lived Vulnerability in Microsoft Secure Boot — Schneier on Security
- 2Forgotten UEFI shims undermining Secure Boot — ESET WeLiveSecurity
- 3VU#616257 - Microsoft-signed UEFI shim bootloaders vulnerable to Secure Boot bypass — CERT/CC