A vulnerability in Secure Boot management

A vulnerability in the management of Secure Boot revocations has allowed over a decade of bypassing one of the primary protection mechanisms for UEFI-based systems. This is highlighted in an analysis by ESET, which states that eleven old bootloader shims signed by Microsoft continued to be considered trustworthy, despite containing already known vulnerabilities, enabling the execution of unauthorized code during the computer's boot process.

The issue affects both Windows and Linux. Shims are small open-source bootloaders designed to allow Linux distributions to boot with Secure Boot enabled. Their operation involves the UEFI firmware verifying their digital signature using the Microsoft certificate present on the motherboard; subsequently, the shim itself authorizes the loading of the second-level bootloader, usually GRUB2, and finally the kernel via embedded certificates.

According to ESET, the risk does not stem from the discovery of a new vulnerability, but rather from the fact that Microsoft had not revoked certain faulty shims distributed since 2013. In practice, an attacker could have replaced an updated version of the shim with an older copy still recognized as valid by the firmware, thereby gaining the ability to execute arbitrary code during the early stages of system boot.

The most critical aspect is that the attack occurs before the operating system and security software are loaded. This enables the installation of UEFI bootkits, malware capable of maintaining persistence even after the operating system is reinstalled or the storage unit is replaced. Examples cited by researchers include BlackLotus, Bootkitty, and HybridPetya, along with other bootkit families already observed in recent years.

ESET emphasizes that exploiting this weakness does not require particularly sophisticated techniques. It is sufficient to have a copy of one of the vulnerable shims still considered reliable and to understand how the UEFI boot chain works. As Martin Smolár, a researcher from the Slovak company, explains, "What makes these old shims dangerous is not a new vulnerability, but the fact that it is unnecessary to discover one to bypass UEFI Secure Boot. All it takes is a copy of a shim still considered trustworthy and a basic understanding of how it operates."

The investigation identified eleven affected bootloaders belonging to various manufacturers and software distributors, including Red Hat, CentOS, Oracle Linux, openSUSE, ROSA Linux, PC-Doctor, Baramundi, Blancco WipeDrive, Spyrus WTGCreator, and the Finnish system Abitti. Many of these components originated from version 0.9 or earlier of the shim project and lacked the latest protections, such as SBAT (Secure Boot Advanced Targeting) and the application of the MOK denylist, introduced specifically to prevent the use of vulnerable components.

The complexity of the Secure Boot ecosystem seems to have contributed to the problem. In addition to the traditional db and dbx databases used respectively for authorizing and revoking certificates and hashes, Microsoft has over time introduced mechanisms such as SBAT and Secure Boot Security Version Number (SVN), which allow entire generations of components to be blocked instead of listing all revoked hashes individually. However, in the case of the eleven shims identified, such revocations had not been applied, leaving vulnerable images valid for years.

The analysis also highlights that the expiration, which occurred on June 27, 2026, of the Microsoft Corporation UEFI CA 2011 certificate does not automatically eliminate the risk. Bootloaders already signed continue to be considered valid until they are explicitly included in the DBX revocation list. For this reason, the mere expiration of the certificate did not prevent the use of vulnerable shims.

The vulnerability is tracked with identifiers CVE-2026-8863 and CVE-2026-10797. Following responsible disclosure by ESET in February, Microsoft included the revocation of the eleven bootloaders in the June 2026 Patch Tuesday, eliminating the issue on updated systems. Windows users who installed the June updates are thus protected, while Linux users are advised to check for the availability of the revocations through their distributor or the Linux Vendor Firmware Service.

Finally, the incident reignites the debate about the current Secure Boot model. Some security experts believe that the reliance on Microsoft as the main trusted authority and the increasing complexity of the revocation mechanism make it difficult to ensure effective protection on a large scale, highlighting the need for an evolution of the entire UEFI boot security ecosystem.