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. ESET reported its 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 — CVE-2026-8863 and CVE-2026-10797 — exploitation of each reported shim is not just about a single bug or two found directly in these old shims. 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 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

Key points:

  • 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 9th, 2026 Patch Tuesday update.

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 19th, 2026 (Microsoft’s May Patch Tuesday).
  • 2026-03-30 – dbx update and public disclosure date was postponed to June 9th, 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.

ESET thanks CERT/CC for its help in coordinating the vulnerability disclosure process, and the affected vendors for transparent communication and cooperation throughout. To protect your systems against this threat, install the latest Microsoft dbx updates.

UEFI Shim Bootloader and UEFI Secure Boot

To understand the impact that vulnerable shims can have on UEFI Secure Boot-protected systems, it is necessary to understand how UEFI Secure Boot works and how signed UEFI shim bootloaders extend the Secure Boot trust chain. This section covers UEFI Secure Boot basics, how UEFI shims extend the trust chain, and two shim-related features: Machine Owner Key (MOK) and Secure Boot Advanced Targeting (SBAT).

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

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 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).