TECH
Forgotten UEFI shims undermining secure boot
ESET researchers identified 11 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-party UEFI certificate authority (CA) certificate, regardless of the installed operating system (OS). Reported shims can be exploited to execute untrusted 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. We reported our findings to CERT/CC in February 2026, and the vulnerable UEFI applications were revoked on Microsoft’s June 9th, 2026 Patch Tuesday.
While 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 directly. In 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. The discovered shims come from various tools or software packages, including PC-diagnostics software, Linux distributions, and other UEFI-based utilities. Importantly, exploitation is not limited to systems with the affected software or OS installed, as attackers can bring their own copy of the vulnerable shims to any UEFI system with the Microsoft third-party UEFI certificate enrolled.
The full list of the software products relying on the reported shims along with their affected versions is available in CERT/CC’s Vulnerability Note. In response to ESET researchers’ report, UEFI shim bootloaders with the following PE Authenticode hashes were revoked in the dbx update that was part of Microsoft’s June 9th Patch Tuesday:
AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4
95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629
Following is the coordinated disclosure timeline. We’d like to thank CERT/CC for its help in coordinating the vulnerability disclosure process, and the affected vendors for smooth and transparent communication and cooperation during the vulnerability disclosure and remediation process. To protect your systems against this threat, install the latest Microsoft dbx updates. Instructions on how to do that can be found in the Protection and detection section.
To understand the impact that such vulnerable shims can have on UEFI Secure Boot-protected systems, we need to understand how UEFI Secure Boot works, and how signed UEFI shim bootloaders extend the Secure Boot trust chain. In this section we’ll look at UEFI Secure Boot basics, how UEFI shims extend the UEFI Secure Boot trust chain, and two shim-related features: Machine Owner Key (MOK) and Secure Boot Advanced Targeting (SBAT). For anyone already familiar with the theory, we recommend jumping directly to the section Bypassing UEFI Secure Boot using old shims.

UEFI Secure Boot...As 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:
db (allowed certificates and Authenticode hashes), and
dbx (forbidden certificates and Authenticode hashes).
The image must be trusted by db and not listed in dbx – otherwise, the boot manager triggers a security violation instead of executing it. To make this work out of the box on newly purchased devices with UEFI Secure Boot enabled, most OEMs enroll a set of Microsoft UEFI certificates in the db database, namely:
-Microsoft Windows Production PCA 2011 and Windows UEFI CA 2023 (used to sign Microsoft’s own UEFI boot applications; the 2011 certificate will be added to dbx soon as a result of the BlackLotus-related vulnerabilities).
-Microsoft Corporation UEFI CA 2011 and Microsoft UEFI CA 2023 (used to sign third-party UEFI boot software, such as Linux shims, recovery tools, and disk encryption utilities).
This means that anyone wanting their boot-time software to be UEFI Secure Boot-compatible by default can submit their binaries to Microsoft for signing through the Windows Hardware Dev Center, and once approved, the signed files become trusted on the vast majority of UEFI systems. As a result, Microsoft plays a central role in securing most UEFI-based devices, effectively deciding what is, and what is not, allowed to run during boot.
mundophone





