ESET Finds 11 Outdated UEFI Shims That Can Bypass Secure Boot
Summary
ESET researchers found 11 outdated, Microsoft-signed UEFI shims that can let attackers run untrusted code at boot and bypass Secure Boot. Microsoft revoked the vulnerable binaries in its June 9, 2026 update.
Key points
- The 11 shims, versions 0.9 and earlier, can be used on UEFI systems that trust Microsoft’s third-party UEFI CA 2011 certificate, even if the affected software or operating system is not installed.
- An attacker can bring a vulnerable shim and its trusted second-stage bootloader, such as GRUB 2, to a target system and use them to execute untrusted code during boot.
- Older shims may ignore later security controls, including MOK denylist enforcement and SBAT revocations; the research also describes a signature-check bypass tracked as CVE-2026-10797.
- The reported shims are covered by CVE-2026-8863 and CVE-2026-10797. Microsoft revoked their hashes in the June 9, 2026 dbx update.
- ESET recommends installing the latest Microsoft dbx updates; Linux revocations should be available through the Linux Vendor Firmware Service.
Article Details
- Attack Vectors
- An attacker can bring an old, Microsoft-signed UEFI shim to a system that trusts Microsoft Corporation UEFI CA 2011, even if the software originally containing that shim is not installed. The shim can then extend trust to vulnerable second-stage bootloaders.
- ESET demonstrated that the reported Oracle Linux shim can load a vulnerable GRUB 2 binary affected by CVE-2015-5281; GRUB 2's multiboot2 command can then execute a custom unsigned image during boot.
- Shims predating MOK denylist enforcement can ignore MokListX while continuing to trust a certificate in MokList, potentially allowing a revoked, vulnerable binary to load.
- Shims predating SBAT support do not enforce SbatLevel revocations and can load second-stage bootloaders that SBAT has revoked.
- In shims at version 0.9 and below, CVE-2026-10797 allows a tampered second-stage bootloader WIN_CERTIFICATE structure to bypass certain certificate-based revocation checks. The article says the bypass does not affect hash-based revocations.
- Defensive Notes
- Install the latest Microsoft UEFI dbx updates, which revoked the 11 reported shims in the 2026-06-09 Patch Tuesday update.
- On Windows, use the article's elevated PowerShell check to verify that the reported shim hashes are present in dbx. The article says Windows systems should receive updates automatically.
- On Linux, obtain updates through the Linux Vendor Firmware Service and check revocation status with the uefi-dbx-audit script.
- ESET explicitly withheld indicators of compromise because the vulnerable shims belong to legitimate software packages and their presence alone does not establish compromise.
MITRE ATT&CK
T1542.003 · BootkitBypassing Secure Boot with a still-trusted old shim can enable installation of a malicious UEFI bootkit; the article also describes bootkits misusing MOKs for persistence after a bypass.T1553.002 · Code SigningThe described attack uses an old shim legitimately signed by Microsoft to pass the system's initial Secure Boot trust check before loading an attacker-selected second-stage bootloader.
CVE
CVE-2015-5281This binary is affected by CVE-2015-5281, which – quoting the vulnerability note – “when used on UEFI systems, allows local users to bypass intended Secure Boot restrictions and execute non-verified code via a craftedCVE-2020-10713As part of the recent "BootHole" security incident CVE-2020-10713, 3 certificates and 150 image hashes were added to the UEFI Secure Boot revocation database dbx on the popular x64 architecture.CVE-2022-34302signing ecosystem to non-shim third-party UEFI applications, which, as repeatedly demonstrated (e.g., CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250, …), can also serve as a straightforward source ofCVE-2023-28005to non-shim third-party UEFI applications, which, as repeatedly demonstrated (e.g., CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250, …), can also serve as a straightforward source of UEFI Secure BootCVE-2024-7344and deployment of UEFI bootkits, see our blogpost Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344.CVE-2026-10797While two CVE IDs were assigned to this case to cover the reported shims, CVE-2026-8863 and CVE-2026-10797, exploitation of each reported shim is not just about a single bug or two that can be found in these old shimsCVE-2026-25250applications, which, as repeatedly demonstrated (e.g., CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250, …), can also serve as a straightforward source of UEFI Secure Boot bypasses.CVE-2026-8863While two CVE IDs were assigned to this case to cover the reported shims, CVE-2026-8863 and CVE-2026-10797, exploitation of each reported shim is not just about a single bug or two that can be found in these old shims
Malware
BlackLotussystem boot, enabling attackers to deploy malicious UEFI bootkits (such as Bootkitty, HybridPetya, or BlackLotus) even on systems with UEFI Secure Boot enabled.Bootkittyuntrusted code during system boot, enabling attackers to deploy malicious UEFI bootkits (such as Bootkitty, HybridPetya, or BlackLotus) even on systems with UEFI Secure Boot enabled.HybridPetyacode during system boot, enabling attackers to deploy malicious UEFI bootkits (such as Bootkitty, HybridPetya, or BlackLotus) even on systems with UEFI Secure Boot enabled.
Vendors
Microsoft0.9 and below that can be used 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, regardlessOracleIt trusts binaries signed by a certificate issued to Oracle Corporation (SHA‑1 thumbprint: 2E434A724B4759C981E4189AA5AD3D635096DD2F).Red HatThe fundamental issue is scale, and it is well captured in the Red Hat Bootloader Team’s SBAT proposal/specification:
Products
Abitti 1shim with an older Microsoft-signed UEFI shim from our report – for example, version 0.8 from the Abitti 1 software, signed by Microsoft for Finland’s Matriculation Examination Board.GRUB 2In fact, the attack surface is extended by the shims’ trusted, second-stage bootloaders (mostly GRUB 2), which – like the shims themselves – may include outdated versions with known vulnerabilities.Oracle LinuxConsider the shim from Oracle Linux, which is among those we reported.Red Hat Enterprise Linuxan attacker takes a Microsoft-signed pre-v15.3 shim – such as the version 0.9 shim from Red Hat Enterprise Linux 7.2 that was part of our report – pairs it with one of the several GRUB 2 binaries that the shimUEFI Secure Boot11 old and forgotten UEFI shim bootloaders at versions 0.9 and below that can be used to bypass UEFI Secure Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Corporation UEFI CA 2011 third-partyWindows 11All UEFI systems with Microsoft third-party UEFI signing enabled are affected (Windows 11 Secured-core PCs should have this option disabled by default).Windows Boot ManagerAs shown in Figure 1, when UEFI firmware loads a boot application – like Windows Boot Manager or a UEFI shim – it verifies the binary against two Secure Boot databases: