Critical UEFI Shim Flaw Lets Attackers Bypass Secure Boot

Key Takeaways

• A critical vulnerability has been discovered in several Microsoft-signed UEFI shim bootloaders, some over a decade old.
• This flaw allows attackers to completely bypass UEFI Secure Boot on virtually any UEFI-based machine, regardless of the operating system.
• Exploitation enables the deployment of malicious UEFI bootkits even when Secure Boot is active.
• Two CVEs (CVE-2026-8863 and CVE-2026-10797) track the issues, and Microsoft has released a dbx update to revoke the vulnerable shims.

Decade-Old UEFI Shim Flaw Undermines Secure Boot

An alarming vulnerability has come to light, revealing that specific Microsoft-signed UEFI shim bootloaders, some dating back as far as 2011, possess critical flaws that permit a complete bypass of UEFI Secure Boot. This exposure affects nearly all UEFI-enabled systems, irrespective of the installed operating system.

Researchers at ESET uncovered that these vulnerable shims, all identified as version 0.9 or earlier, were digitally signed by Microsoft’s “Microsoft Corporation UEFI CA 2011” certificate. Despite containing known, exploitable weaknesses, these binaries have remained trusted components within the boot process for years.

The implications are severe: an attacker leveraging these shims can execute arbitrary, untrusted code during the crucial boot phase. This capability paves the way for deploying sophisticated malicious UEFI bootkits, such as Bootkitty, HybridPetya, or BlackLotus, even on systems where Secure Boot is fully enabled and configured.

Crucially, the threat extends beyond machines running specific affected software or Linux distributions. An adversary can introduce their own copy of a vulnerable shim to any system that recognizes Microsoft’s third-party UEFI certificate, effectively turning a secure system into a vulnerable one.

The Mechanics of the Bypass

UEFI shim bootloaders serve as an essential intermediary. Microsoft signs these first-stage components once, enabling various Linux distributions to boot successfully under Secure Boot without requiring each vendor to embed unique keys into every motherboard. The shim’s role is to then transfer trust to a second-stage bootloader, typically GRUB 2, using vendor-managed certificates.

The core problem lies in the age of many of these shims. They lack contemporary anti-revocation mechanisms, specifically the proper enforcement of the Machine Owner Key denylist (MokListX) and Secure Boot Advanced Targeting (SBAT). Both of these critical protections were introduced long after the vulnerable binaries were originally signed.

This deficiency means an attacker can pair an outdated shim with a GRUB 2 binary that has been separately revoked or is known to be vulnerable. The old shim, unaware of modern revocation lists, will simply fail to reject the malicious GRUB 2 component. The exploitation method mirrors a Bring Your Own Vulnerable Driver (BYOVD) attack, where the malicious shim and GRUB 2 pair can be placed directly onto the EFI System Partition and executed before the operating system even begins to load.

Vulnerability Tracking and Remediation

Two distinct CVE identifiers have been assigned to formally track these critical issues:

• CVE-2026-8863: This identifier addresses the primary shim-bypass vulnerability reported to CERT/CC.
• CVE-2026-10797: This covers a decade-old flaw in the shim’s revocation check mechanism, where it incorrectly reads the signature size from the PE structure. This allows attackers to completely circumvent dbx/MokListX revocation.

CERT/CC’s official vulnerability note confirms that the affected shims primarily originate from version 0.9 and earlier of the open-source shim project. These vulnerable components are found across various platforms, including PC-diagnostics tools, numerous Linux distributions, and other UEFI utilities.

ESET reported its findings to CERT/CC in February 2026. Following a period of coordination, Microsoft took action, revoking all 11 identified vulnerable shim binaries through a dbx update released on June 9th, 2026, as part of their Patch Tuesday rollout.

Once this update is applied, Secure Boot firmware will prevent the loading of any flagged shim versions by checking their SHA-256 Authenticode hashes against the forbidden signature database. It is important to note that all UEFI systems with Microsoft’s third-party UEFI signing enabled are exposed, though Windows 11 Secured-core PCs offer some inherent protection as this option is disabled by default.

What You Should Do

Security teams and end-users must approach the deployment of this patch with caution to prevent potential boot failures.

• Deployment Order: Crucially, deploy the updated authorized signature database (db) first, and only then apply the dbx revocation list. Reversing this order can lead to systems rejecting legitimate, signed bootloaders.
• Windows Systems: Windows users should receive the dbx update automatically through standard Patch Tuesday channels.
• Linux Users: Linux users should actively check for updates via the Linux Vendor Firmware Service (LVFS) and verify their revocation status using the uefi-dbx-audit script.
• Enterprise Testing: Enterprises should conduct thorough testing of the update on non-critical hardware before initiating a broad rollout. Improper deployment order can render systems unbootable.
• Verification: Administrators can utilize PowerShell audit scripts to confirm that the necessary SHA-256 hashes are correctly present in their dbx variable.

This incident highlights a persistent challenge within the UEFI signing ecosystem: a lack of visibility. Many shims signed before 2017, predating the establishment of the shim-review transparency process, remain largely unaccounted for. This suggests that additional forgotten, exploitable binaries could still be trusted on systems globally, posing an ongoing risk.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.