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 9 th , 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 9 th Patch Tuesday : AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961 7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10 EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5 A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4 95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06 236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B 5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B 8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963 410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373 96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629 Key points of this blogpost: ESET researchers discovered 11 old, Microsoft-signed, UEFI applications that allow bypassing UEFI Secure Boot on the majority of UEFI-based systems. An attacker exploiting one of these vulnerable applications can execute untrusted code during system boot, enabling deployment of malicious UEFI bootkits or other malware. Exploitation is not limited to systems with the affected software or OS installed, as attackers can bring their own copy of the vulnerable binaries to any UEFI system with the Microsoft third-party UEFI certificate enrolled. All UEFI systems with Microsoft third-party UEFI signing enabled are affected (Windows 11 Secured-core PCs should have this option disabled by default). The vulnerable binaries were revoked by Microsoft in the June 9 th , 2026 Patch Tuesday update. 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. Coordinated disclosure timeline: 2026-02-16 – ESET reported the findings, along with a proof of concept, to CERT/CC. 2026-03-18 – dbx update and public disclosure date was set to May 19 th , 2026 (Microsoft’s May Patch Tuesday). 2026-03-30 – dbx update and public disclosure date was postponed to June 9 th , 2026 (Microsoft’s June Patch Tuesday). 2026-06-09 – Microsoft’s June Patch Tuesday update, CERT/CC Vulnerability Note published. 2026-07-14 – ESET blogpost published. UEFI shim bootloader and UEFI Secure Boot 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). Figure 1. UEFI Secure Boot simplified scheme (source: UEFI Bootkits and Where UEFI Security Fails , p. 48) 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. UEFI revocation (dbx) UEFI Secure Boot’s revocation design is straightforward: when a previously trusted boot application – one whose PE authenticode hash, or the certificate that signed it, is present in db – turns out to be vulnerable, its PE authenticode hash is added to dbx , the Microsoft-managed forbidden-signatures database (with the latest dbx contents typically published in Microsoft’s GitHub repository ). Certificates themselves are revoked only occasionally. While the original idea of revoking individual vulnerable binaries by hash might have been reasonable at the time Secure Boot was introduced, cases such as BootHole and BlackLotus demonstrate that this approach is far from ideal. The fundamental issue is scale, and it is well captured in the Red Hat Bootloader Team’s SBAT proposal/specification: As 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. This single revocation event consumes 10kB of the 32kB, or roughly one third, of revocation storage typically available on UEFI platforms. Due to the way that UEFI merges revocation lists, this plus prior revocation events can result in a dbx that is almost 15kB in size, approaching 50% capacity. The same pressure on dbx capacity surfaced again with the BlackLotus-related revocations of vulnerable Windows Boot Manager binaries. Both of these prompted Microsoft, together with its partners, to introduce additional, version-based revocation mechanisms, each tied to one of the two widely deployed Secure Boot-compatible bootloaders: Secure Boot Advanced Targeting (SBAT) – used by shim, a UEFI bootloader for Linux, from version 15.3 . Microsoft’s Secure Boot Security Version Number (SVN) – used by Windows Boot Manager (released in April 2024) – also referred to as Revocation via Embedded Secure Version Information (REVISE) in Bill Demirkapi’s Booting with Caution, p. 62 ; however, this name and acronym do not seem to be used in the official Microsoft documentation. In short, where dbx revokes binaries , SBAT and Microsoft’s Secure Boot SVN revoke versions . When a vulnerability is found in a UEFI application supporting one of these version-based revocation mechanisms, what really needs to be kept out is every build up to and including the broken one – and that can be captured by a version number much easier than by a long list of hashes. We explain more about SBAT in the Secure Boot Advanced Targeting (SBAT) section. UEFI shim bootloader and Secure Boot With Linux distributions supporting UEFI Secure Boot, the above-described Secure Boot mechanism built around Microsoft keys introduces some challenges. Every Linux distribution generates its own bootloader binaries, and each of them has a different hash. Getting every Linux bootloader signed directly by Microsoft would be slow, bureaucratic, and impractical (if not impossible) to maintain across all Linux distributions. The solution to this problem is a shim: a small, minimal first-stage bootloader that Microsoft can vet and sign once, and which then creates a secondary trust anchor for the rest of the Linux distribution-specific boot stack – usually GRUB 2 and the Linux kernel. This trust anchor is another certificate, referred to as a vendor certificate (managed by the distribution vendor), added to the shim binary before it is signed by Microsoft. A simplified boot sequence on a Secur