For more than a decade, eleven tiny bootloaders quietly passed through the most critical security checkpoint in modern computing — and no one in the industry noticed. ESET researchers disclosed on July 14 that they had identified eleven Microsoft-signed UEFI shim bootloaders, some dating back over a decade, that could allow an attacker to completely bypass UEFI Secure Boot on virtually any PC on the planet. The discovery is a sobering reminder that the firmware security layer millions of enterprises rely on as a foundational trust anchor has had multiple invisible cracks for years.
What Is a UEFI Shim, and Why Should You Care?
To understand what went wrong, it helps to understand what a shim actually does. UEFI Secure Boot is the mechanism that ensures only cryptographically trusted software runs before your operating system loads. Every component in the boot chain must carry a valid signature that traces back to a certificate stored in firmware — most commonly, the “Microsoft Corporation UEFI CA 2011” certificate that comes pre-installed on the overwhelming majority of UEFI-based computers shipped over the last fifteen years.
Linux distributions cannot practically embed their own keys in every motherboard shipped worldwide, so they use a shim: a small, open-source first-stage bootloader that Microsoft signs once. The shim’s job is to act as a trusted intermediary. It carries Microsoft’s signature, the firmware trusts it, and then the shim uses its own embedded vendor certificate to validate GRUB 2, which in turn validates the Linux kernel. One trusted bridge, connecting the Microsoft-controlled root of trust to the diverse ecosystem of Linux distributions.
What ESET researcher Martin Smolár found is that eleven of these shims — all at version 0.9 or earlier — were signed and shipped at a time before critical revocation mechanisms existed. Specifically, these old shims lack proper enforcement of the Machine Owner Key denylist (MokListX) and Secure Boot Advanced Targeting (SBAT), both of which were introduced to allow the boot chain to reject known-bad components without recompiling firmware. An attacker with administrative privileges on a target machine — or with physical access — can simply drop one of these ancient but still-trusted shim files onto the EFI System Partition and execute it before the operating system ever loads.
An Attack That Doesn’t Need a Novel Exploit
What makes this disclosure particularly alarming is ESET’s blunt assessment: “What makes these old shims dangerous is not a novel vulnerability — it’s that no new vulnerability is needed to bypass UEFI Secure Boot.” An attacker does not need a sophisticated exploit chain. They need a copy of an old shim binary and basic knowledge of how the UEFI boot process works.
The attack pattern resembles a Bring Your Own Vulnerable Driver (BYOVD) technique, a method that has gained notoriety in the endpoint detection and response (EDR) evasion community. Here, the “vulnerable driver” is a decades-old shim binary that Microsoft signed in good faith and never explicitly revoked — until now. An attacker pairs the ancient shim with a separately revoked GRUB 2 binary, drops both onto the EFI System Partition, and boots. Because the shim lacks the revocation-checking machinery introduced in later versions, it simply does not know to reject its companion.
The consequence is full pre-OS code execution. From that position, an attacker can deploy UEFI bootkits — malware that survives operating system reinstallations and can hide beneath every security product the victim installs. Known UEFI bootkit families capable of exploiting this entry point include Bootkitty, HybridPetya, and BlackLotus. All of them achieve persistence that is essentially invisible to conventional endpoint security tools, which only initialize after the firmware hands off control to the OS.
Eleven Vendors, One Root Cause
Smolár reported the findings to CERT/CC in February 2026 after identifying the affected binaries. The CERT Coordination Center confirmed in its advisory that the vulnerable shim bootloaders spanned a diverse array of products that all shared the same fundamental flaw: they were signed during an era before the shim community had established proper revocation infrastructure, and no one had gone back to revoke them.
The full list of affected products reads like a cross-section of the enterprise and professional Linux ecosystem:
- Spyrus WTGCreator — USB-based portable Windows-to-Go creator tool, shim version 0.7 or lower
- Red Hat Enterprise Linux 7.2 — shim version 0.9
- CentOS 7.2 — shim version 0.9
- Baramundi Management Suite (up to 2024R1) — shim version 0.8, enterprise endpoint management
- WhiteCanyon/Blancco WipeDrive (8.0.0–8.1.3) — shim version 0.7, secure data erasure tools used by IT asset disposition teams
- Abitti 1 from Finland’s Matriculation Examination Board — shim version 0.8
- ROSA Linux (R10, R9) from NTC IT ROSA — shim version 0.9
- Oracle Linux 7.2 — shim version 0.9
- PC-Doctor Service Center (versions 15, 16) — shim version 0.9, a hardware diagnostics tool
- OpenSUSE UEFI Shim loader — version 0.9
- OpenSUSE Shim 2.1 — from UEFI Shim loader 0.9
Critically, the exposure is not limited to machines actually running these distributions or tools. Because the shims carry Microsoft’s signing certificate, they are trusted by any UEFI system with the Microsoft Corporation UEFI CA 2011 certificate active — meaning virtually every enterprise workstation, server, and laptop manufactured in the past decade. An attacker can bring a vulnerable shim to a target machine running a completely different operating system and the firmware will load it without question.
A Second CVE and a Subtler Flaw
Two CVE identifiers cover the disclosure. CVE-2026-8863 addresses the primary shim bypass issue reported to CERT/CC. CVE-2026-10797 is technically separate and older — it describes a flaw in which the shim reads the signature size from the wrong field in the PE executable structure, allowing an attacker to dodge dbx and MokListX revocation checks entirely. This second flaw had been patched in the upstream shim project years ago, but many of the affected vendor shims were never updated to incorporate the fix. They remained signed, trusted, and vulnerable.
CERT/CC’s advisory highlighted the systemic nature of the problem: “Vulnerable bootloaders remained signed and trusted by Secure Boot systems because they had not been revoked through the Microsoft-signed DBX revocation list. This created a long-term supply chain exposure in which outdated and vulnerable boot components could still be executed on fully patched systems.”
Microsoft’s Response and What Defenders Should Do Now
Microsoft revoked all eleven vulnerable shim binaries as part of its June 9, 2026 Patch Tuesday update, adding their SHA-256 Authenticode hashes to the DBX (UEFI forbidden-signature database). Windows systems received this update automatically through standard Windows Update channels. Linux administrators need to act more deliberately.
ESET and CERT/CC both advise the following deployment order: install the updated authorized signature database (db) first, and only then apply the DBX revocation list. Reversing this sequence can leave systems unable to boot if the updated db does not yet include the replacement shims that replace the revoked ones. Linux users should check for updates through the Linux Vendor Firmware Service (LVFS) and can use the uefi-dbx-audit script to verify revocation status.
Enterprise security teams should test the update on non-critical hardware before broad rollout. Administrators can use PowerShell audit scripts to confirm the necessary SHA-256 hashes are present in the dbx variable on Windows machines.
One important note: the expiration of the Microsoft Corporation UEFI CA 2011 certificate on June 27, 2026, does not automatically protect against these shims. Certificate expiration does not trigger revocation in UEFI Secure Boot; only explicit hash entries in the DBX database do.
The Deeper Problem This Reveals
The disclosure surfaces a visibility gap that has existed since the beginning of the shim signing ecosystem. The shim-review transparency process, which subjects new shim submissions to community scrutiny before Microsoft signs them, only began in 2017. Any shim signed before that date received no such oversight, and there is no comprehensive public inventory of what was signed. ESET’s assessment is that more forgotten, exploitable shim binaries almost certainly still exist in the wild, trusted by firmware worldwide, waiting to be weaponized.
For enterprise security teams, the immediate remediation is clear: apply the June patches, verify DBX content, and audit UEFI boot configurations. The longer-term implication is harder to solve. The firmware security layer that underpins endpoint trust chains across the entire industry spent more than a decade accumulating technical debt, and the community is only now beginning to understand the full scope of what was signed — and what was never revoked.
Sources: The Hacker News | Cyber Security News | ESET WeLiveSecurity | CERT/CC VU#616257 | Help Net Security
