UEFI Secure Boot Bypass: 11 Microsoft-Signed Shims, Some Over a Decade Old, Trusted by Every UEFI Computer — No Exploit Needed, Bootkits Load Before EDR

Sources: ESET Research — “Forgotten UEFI Shims Undermining Secure Boot” (Martin Smolár, WeLiveSecurity primary research) · ESET Press Release (Globe Newswire, July 14, 2026) · The Hacker News · Help Net Security · Latest Hacking News · SC Media · MLQ News | CVEs: CVE-2026-8863 · CVE-2026-10797 | CERT/CC tracking: VU#616257 | Discovered by: ESET researcher Martin Smolár | Reported to CERT/CC: February 16, 2026 | Revoked by Microsoft: June 9, 2026 Patch Tuesday (dbx update) | Vulnerable shims: 11 — all version 0.9 and below, all Microsoft-signed | Affected systems: All UEFI systems trusting Microsoft Corporation UEFI CA 2011 certificate — described as the vast majority of UEFI computers worldwide, regardless of OS | Attack complexity: No new exploit needed — file copy sufficient | Bootkits enabled: Bootkitty · HybridPetya · BlackLotus | Wild exploitation: None confirmed prior to disclosure | Unknown risk: ESET cannot confirm how many additional unrevoked vulnerable shims remain undiscovered — shim-review repository only tracks from 2017

“No new vulnerability is needed to bypass UEFI Secure Boot. An attacker needs only a copy of an old, still-trusted but unrevoked shim binary and a basic understanding of how UEFI shims work.”

On July 14, 2026, ESET researcher Martin Smolár published the technical disclosure for eleven old, Microsoft-signed UEFI shim bootloaders — some more than a decade old — that remained trusted by virtually every UEFI-based computer in the world and could be used to bypass Secure Boot without a single new exploit. The vulnerable binaries were revoked by Microsoft in the June 9, 2026 Patch Tuesday dbx update following ESET’s responsible disclosure in February. The disclosure is public now. The patch is available. And an unknown number of additional unrevoked vulnerable shims may still exist in Microsoft’s historical signing catalog — because the shim-review repository that documents signed shim submissions only tracks from 2017 onward, and these eleven shims predate that record.

The quote from ESET’s disclosure that defines the entire finding: “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 needs no complicated exploitation primitives — only a copy of an old, still-trusted but unrevoked shim binary and a basic understanding of how UEFI shims work. That is enough to bypass such an essential security feature as UEFI Secure Boot.”

Secure Boot bypass enabling bootkit deployment is the highest persistence class of malware known. A bootkit that executes during the boot process, before the operating system loads, before any antivirus, before any EDR, survives OS reinstalls, is invisible to all software-layer security tools, and in some configurations persists across drive replacements. ESET’s own BlackLotus coverage, Bootkitty, and HybridPetya are the known bootkits that these eleven shims would have trivially enabled. The remediation is available and should be applied immediately — but the systemic problem these shims reveal is not fully resolved by patching them.

What UEFI Secure Boot is — and why bypassing it is the worst possible outcome

UEFI Secure Boot is the firmware-level trust chain that guarantees the code running at the very beginning of the boot process — before the operating system, before any drivers, before any security software — is code that has been cryptographically verified and not tampered with. The design principle: the motherboard’s UEFI firmware trusts only cryptographically signed boot components. Unsigned or tampered components are rejected before they can execute. The trust chain extends from firmware to bootloader to OS kernel to drivers.

Bypassing Secure Boot breaks this chain at its root. An attacker who can execute code before the operating system loads can:

• Deploy a bootkit — malware that persists in the UEFI firmware or boot partition and executes before any OS or security software loads, invisible to all software-layer detection tools
• Survive OS reinstalls — a bootkit in the EFI system partition or firmware persists even if the operating system is completely reinstalled, because the bootkit executes before the OS and can re-infect it
• Disable security software before it loads — the bootkit executes before EDR, AV, or any kernel security feature initializes, allowing it to disable, bypass, or manipulate those tools before they have a chance to detect the bootkit itself
• Compromise measured boot and attestation — systems that use TPM-based measured boot attestation (including some Zero Trust hardware attestation models) can be manipulated at the boot measurement stage, potentially allowing a compromised system to attest as trusted

This is why Secure Boot bypass is categorically more dangerous than application-layer vulnerabilities. An application-layer exploit has to contend with EDR, AV, kernel security features, and detection pipelines. A boot-level exploit runs before all of them exist.

What a UEFI shim is — and how eleven of them became a master key

A UEFI shim is a lightweight first-stage bootloader — typically a few hundred kilobytes of code — whose sole purpose is to bridge the gap between a computer’s UEFI firmware and a Linux operating system. The problem: UEFI firmware is typically configured to trust only Microsoft-signed boot components. Linux distributions are not signed by Microsoft directly. The shim solves this by being signed by Microsoft, then verifying the Linux bootloader (usually GRUB 2) using its own embedded certificate before handing off control.

Microsoft signs these shims under the Microsoft Corporation UEFI CA 2011 certificate — the third-party UEFI signing certificate that has been used to sign external boot components for more than a decade. Any UEFI system with this certificate in its db (trusted signatures database) trusts every binary Microsoft has signed under it — unless that specific binary’s hash has been added to the dbx (forbidden signatures database). Revocation in UEFI happens by hash, not by certificate. A certificate expiring does not revoke the binaries signed under it.

This is where the problem starts. The Microsoft Corporation UEFI CA 2011 certificate expired on June 27, 2026. But ESET’s finding — and the core of Martin Smolár’s research — is that certificate expiry is irrelevant to Secure Boot verification. A binary signed by the expired certificate is trusted by a UEFI system as long as: (a) the certificate is still in the system’s db, and (b) the binary’s hash is not in the system’s dbx. For eleven specific shim binaries at version 0.9 and below, condition (b) was not met. Their hashes were not in the dbx. They were trusted by virtually every UEFI computer in the world — including every Windows PC and server.

The attack — why it required no new exploit

The standard BYOVD (Bring Your Own Vulnerable Driver) attack pattern — placing a known-vulnerable signed driver on a system to exploit it — applies directly here. An attacker copies one of the eleven vulnerable shim binaries to a target system’s EFI system partition. They do not need the vulnerable software to be already installed. They do not need to exploit a vulnerability on the running system first. They need:

1. A copy of one of the eleven vulnerable shim binaries (publicly available, signed by Microsoft)
2. The ability to write to the target’s EFI system partition (requires local admin or physical access on Windows; root on Linux)
3. A matching second-stage bootloader (typically a modified GRUB 2) to receive control from the shim

Once the vulnerable shim is in place and the system is rebooted, the UEFI firmware validates the shim’s Microsoft signature — it passes — and hands control to the shim. The shim’s own verification of the next bootloader is where the weakness lies. Two independent vulnerabilities exist across the eleven shims:

• CVE-2026-8863 — covers the primary Secure Boot bypass capability of the eleven shims
• CVE-2026-10797 — a long-patched issue in shim version 0.9 and below where the revocation check and the signature verification function used different size values from the same binary structure (IMAGE_DIRECTORY_ENTRY_SECURITY vs WIN_CERTIFICATE), creating a divergence that allowed the certificate-based revocation mechanism to be bypassed by modifying the second-stage bootloader’s signature header. This vulnerability was fixed almost exactly a decade ago in upstream shim commit d241bbb but had no CVE ID until Smolár’s report.

From the EFI system partition, the attacker’s modified bootloader loads next, also trusted because it was verified (or verification was bypassed) by the shim. Then a bootkit is deployed — Bootkitty, HybridPetya, BlackLotus, or any equivalent — which executes before the OS kernel initializes. The system boots into the OS normally, appearing completely healthy to the user, while the bootkit operates at a layer below all detection.

The systemic problem — an unknown number of additional vulnerable shims may still exist

Smolár’s disclosure closes eleven specific shims. But it surfaces a structural audit problem that eleven revocations do not resolve: no one knows how many additional vulnerable shims are still trusted.

The shim-review repository — the primary public record of Microsoft-signed shim submissions — was started in 2017. It documents every shim submitted for signing since then. It does not document shims signed before 2017. The Microsoft Corporation UEFI CA 2011 certificate was signing third-party UEFI components since at least 2011 — more than six years before any systematic record exists. As Help Net Security summarizes: “ESET itself cannot say how many forgotten shims remain undiscovered.” The eleven found by Smolár represent a known-discovered subset of an unknown total population.

ESET’s recommendation at the end of their primary research blog addresses this directly: the next step is extending shim-review-level transparency to all Microsoft-signed UEFI applications, not just shims — because as they note, non-shim third-party UEFI applications have repeatedly served as Secure Boot bypass vectors (CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250). The eleven shims are eleven known holes in a fence whose full perimeter remains unmapped.

Why the bootkits this enables are the worst-case malware outcome

The three bootkits ESET specifically identifies as enabled by these shims — Bootkitty, HybridPetya, and BlackLotus — share a common property: they all execute before any software-layer security control has initialized. BlackLotus in particular, which DataWater has covered as part of the UEFI bootkit threat arc, was the first in-the-wild UEFI bootkit to bypass Secure Boot on fully updated Windows 11 systems. It targets Secure Boot precisely because doing so makes every subsequent security control irrelevant.

From the perspective of incident response, a bootkit creates a uniquely difficult detection and remediation problem:

• Standard EDR cannot see it — EDR loads after the bootkit and cannot detect what was running before it initialized
• AV scanning is ineffective — AV scans files on the filesystem; the bootkit executes from the EFI partition before the filesystem is mounted in the normal sense
• OS reinstall does not remove it — a bootkit on the EFI partition or in firmware survives OS reinstall and re-infects the new OS installation at next boot
• Memory forensics is unreliable — the bootkit controls what the OS kernel can observe about memory at boot time
• Confirmed remediation may require reflashing firmware — in some bootkit deployments, complete remediation requires UEFI firmware reflash, not just OS reinstall or drive wipe

Remediation — verified steps for Windows and Linux

Windows

1. Apply the June 9, 2026 Patch Tuesday cumulative update (KB number varies by Windows version) — this delivers the dbx update that adds all eleven revoked shim hashes to the forbidden signatures database
2. Verify the dbx update was applied: Get-SecureBootUEFI -Name dbx | Format-List — confirm the output shows a dbx dated June 2026 or later
3. Windows 11 Secured-core PCs: verify that “Allow Microsoft third-party UEFI certificates” is OFF in UEFI/BIOS firmware settings
4. Audit the EFI system partition for unexpected .efi files: mountvol X: /S then dir X:\EFI\ /s — investigate any unexpected bootloader files
5. Run ESET’s PowerShell verification script (available from WeLiveSecurity.com) to confirm the eleven revoked shim hashes are present in dbx

Linux

1. Update via the Linux Vendor Firmware Service: fwupdmgr refresh && fwupdmgr update
2. Verify with the uefi-dbx-audit tool: uefi-dbx-audit -d /sys/firmware/efi/efivars/dbx-*
3. Audit EFI partition for unexpected bootloader files: ls -la /boot/efi/EFI/
4. Check shim version if Linux uses shim: shimx64.efi --version should report 15.x or later, not 0.9 or below

Air-gapped and legacy systems

Systems that do not receive automatic dbx updates — air-gapped networks, systems managed through manual patch processes, legacy hardware with infrequent firmware updates — are the highest-risk category. The dbx update must be explicitly applied via bootable USB or offline update mechanism. This is not optional patching — it is closing a Secure Boot bypass that enables bootkit deployment.

Sources and further reading

• ESET Research — “Forgotten UEFI Shims Undermining Secure Boot” (Martin Smolár, Primary Research)
• The Hacker News — 11 Old Microsoft-Signed Linux UEFI Shims Could Let Attackers Bypass Secure Boot
• Help Net Security — No One Knows How Many Old Shims Can Still Bypass UEFI Secure Boot
• Latest Hacking News — 11 Old Signed UEFI Shims Just Broke Secure Boot on Millions of PCs
• SC Media — Old Microsoft-Signed UEFI Applications Can Bypass Secure Boot
• MLQ News — ESET Finds 11 Microsoft-Signed UEFI Shims That Bypassed Secure Boot for Over a Decade

DataWater publishes daily cybersecurity intelligence for enterprise and government security leaders. Article #42 — July 15, 2026. Previous: CitrixBleed 2 — Seven Steps to DragonForce Ransomware (July 13) · JADEPUFFER — First AI Agent Ransomware (July 9) · Bad Epoll CVE-2026-46242 (July 5). Browse the full threat brief archive →