Forgotten UEFI shims undermining Secure Boot

ESET researchers identified 11 old and forgotten UEFI shim bootloaders at versions 0.9 and below that could be exploited to bypass UEFI Secure Boot on most UEFI-based systems. Reported shims can be used to execute untrusted code during system boot, enabling deployment of malicious UEFI bootkits, such as Bootkitty, HybridPetya, or BlackLotus, even on systems with UEFI Secure Boot enabled. The vulnerabilities were discovered on February 16th, 2026, and a proof of concept was reported to CERT/CC. Microsoft addressed the issue in its June 9th, 2026 Patch Tuesday update, revoking the vulnerable UEFI applications.

However, the discovery reveals a deeper problem with UEFI Secure Boot revocation. Relying solely on binary hashes to identify vulnerable bootloaders is insufficient due to the limitations of revocation storage. The UEFI Secure Boot database (dbx) has a finite capacity, and a single revocation event can consume a significant portion of this space – approximately one third – leading to a dbx that approaches 50% capacity. This has been exacerbated by events like BootHole and BlackLotus, requiring Microsoft and its partners to introduce version-based revocation mechanisms.

The vulnerable shims come from various tools and software packages, including PC-diagnostics software, Linux distributions, and other UEFI-based utilities. Exploitation is not limited to systems with the affected software or OS installed; attackers can bring their own copy of the vulnerable binaries to any UEFI system with Microsoft’s third-party UEFI certificate enrolled. This means that even systems with UEFI Secure Boot enabled, if they trust Microsoft’s UEFI certificates, are vulnerable.

Microsoft plays a central role in securing most UEFI-based devices, deciding what is, and what is not, allowed to run during boot. The original idea of revoking individual vulnerable binaries by hash might have been reasonable at the time Secure Boot was introduced, but 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.

To understand how this works, consider the UEFI Secure Boot process. 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. To make this work out of the box on newly purchased devices, 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) and 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. The discovery highlights the importance of understanding how UEFI Secure Boot works and the challenges of managing revocation in a complex ecosystem.

UEFI revocation (dbx) 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.

Version-based revocation mechanisms, such as Secure Boot Advanced Targeting (SBAT) and Microsoft’s Secure Boot SVN, have been introduced to address these limitations. The incident underscores the importance of a layered approach to security and the need for ongoing vigilance in managing UEFI vulnerabilities.