Nearly a dozen Unified Extensible Firmware Interface (UEFI) shim bootloaders signed by Microsoft allow attackers to bypass Secure Boot protections, ESET warns.
Small, trusted pieces of software bridge a computer motherboard’s UEFI firmware and the operating system, typically a Linux distribution, enabling the machine to boot with Secure Boot enabled.
By using Microsoft-signed UEFI shim bootloaders, Linux distributions can establish a trust model without requiring individual keys to be built into the motherboard’s NVRAM. The shims allow bootloaders, kernels, and other components to run during Secure Boot.
While various vulnerabilities have been addressed in the open source shim project over time, not all vendors updated their bootloaders, and these older shims remained signed and trusted within the Secure Boot chain, exposing systems to potential attacks.
According to ESET, 11 such old, forgotten UEFI shims, primarily from version 0.9 and earlier, lingered around until revoked by Microsoft on June 2026 Patch Tuesday. Two CVEs were assigned, namely CVE-2026-8863 and CVE-2026-10797.
The vulnerable shims, ESET says, could be exploited to “bypass UEFI Secure Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Corporation UEFI CA 2011 third-party UEFI certificate authority (CA) certificate, regardless of the installed operating system (OS).”
Coming from various tools and packages, these shims extend the attack surface through their trusted second-stage bootloaders. Additionally, attackers could bring their own vulnerable shims to systems that have enrolled the Microsoft third-party UEFI certificate.
“Signing and compilation timestamps of the applications trusted by the shims we reported span from 2013 to 2025 – enough to confirm that a significant portion of these binaries were old and likely affected by numerous publicly known vulnerabilities, [such as] BootHole in the case of GRUB2,” ESET notes.
Continuous trust in these old, vulnerable shims allows attackers to execute untrusted code during the boot process and deploy bootkits even if Secure Boot is enabled.
ESET reported the findings to CERT/CC in February 2026. In June, Microsoft revoked all vulnerable applications and added them to the UEFI DBX (Forbidden Signature Database). According to CERT/CC, system admins should update the signature database (DB) before applying DBX revocations.
“In practice, this means updating trusted boot applications and certificates first, followed by deployment of the revocation list. Failure to follow this order may cause systems to reject newly updated boot components. Enterprises, virtualization providers, and cloud operators managing large-scale deployments should prioritize validation and deployment of these updates to prevent the execution of vulnerable or unsigned binaries during physical or virtual machine startup,” CERT/CC notes.
Since 2017, shims have been signed and documented after a vetting process, but those approved before then are not documented, and many old, still-trusted shims may remain, potentially exposing systems to attacks.
Related: New Exploit Bypasses Apple’s Boot Defenses, Affects Millions of iPhones
Related: Nightmare Eclipse Drops ‘LegacyHive’ Windows Zero-Day
Related: Trend Micro, Tanium, ESET and Tenable Patch Severe Product Vulnerabilities
Related: Unpatched Cursor Vulnerability Exposes Users to Code Execution
