Vulnerabilities in Microsoft-Signed UEFI Shims Pave the Way for Attacks
Recent findings from cybersecurity research firm ESET reveal that attackers can exploit vulnerabilities in 11 Microsoft-signed UEFI shim bootloaders, potentially impacting a wide array of computer systems. These vulnerabilities have remained hidden for over a decade, raising significant concerns about the integrity of Secure Boot mechanisms present in UEFI-compatible systems.
ESET’s experts reported these concerning shims to the CERT Coordination Center (CERT/CC) in February 2026. All of these shims are versions 0.9 or below and are signed under Microsoft’s Microsoft Corporation UEFI CA 2011 third-party certificate. This particular signing allows any UEFI system that recognizes that certificate to accept the shims, regardless of the installed operating system. This means that if a system trusts the certificate, it essentially becomes susceptible to manipulation through these vulnerabilities.
Exploitation of these vulnerabilities permits the execution of untrusted code during the boot sequence. This paves the way for the installation of UEFI bootkits, including well-known strains like Bootkitty, HybridPetya, and BlackLotus. Alarmingly, these security threats can be activated even with Secure Boot enabled, which is intended to protect against such unauthorized code.
Understanding the Mechanism: Old Code with No Exploit Required
A shim serves as a small first-stage bootloader that Microsoft signs once, allowing various Linux distributions to boot under Secure Boot without needing to submit every minor update for new signing. However, the serious risk associated with the vulnerable shims lies in the outdated second-stage bootloaders they trust, primarily GRUB 2. The signing timestamps for these trusted binaries range from 2013 to 2025, and earlier versions of GRUB 2 are known to harbor significant vulnerabilities.
To illustrate this issue, ESET demonstrated the risks using a shim from Oracle Linux that trusts a GRUB 2 binary vulnerable to a flaw discovered back in 2015. This flaw allows for unsigned code to be loaded through manipulated multiboot modules. The exploit does not even require any sophisticated techniques like memory corruption or reverse engineering. An attacker can simply construct an unsigned kernel image, place it alongside the old shim and GRUB 2, and execute it with a single command during the boot process.
Evasion of Recent Security Measures
The vulnerabilities in these shims also enable attackers to sidestep recently implemented security mechanisms designed to catch such exploits. Notably, the enforcement of the Machine Owner Key (MOK) denylist was introduced only with shim version 0.9, leaving older shims oblivious to it. Thus, attackers can load binaries that organizations believed had been revoked, rendering the MOK denylist useless against these vulnerabilities.
Additionally, the same oversight applies to the Secure Boot Advanced Targeting (SBAT) policy, a version-based revocation system that was introduced in shim version 15.3. Shims that were signed prior to this version fail to check the SBAT policy, allowing them to operate without scrutiny despite the presence of known vulnerabilities.
The broader issue lies in visibility and transparency, according to ESET. Submission records for shims have only been cataloged openly since 2017, leaving organizations in the dark regarding how many older, unexamined shims still circulate in the digital ecosystem.
To formally address these vulnerabilities, two CVE IDs, CVE-2026-8863 and CVE-2026-10797, have been assigned to the reported shims. Microsoft took action by revoking these vulnerable binaries in an update provided during its June 9 Patch Tuesday, ultimately mitigating a significant portion of the threat.
Recommendations for Users
Typically, Windows machines receive these updates automatically, ensuring that users benefit from the latest security measures with minimal effort. However, for Linux users, it is recommended that they retrieve the revocation through the Linux Vendor Firmware Service to ensure full protection.
ESET has made it clear that, due to the nature of these vulnerable shims being embedded within legitimate software packages, which have potentially been installed on thousands of uncompromised systems, they are refraining from providing specific indicators of compromise. They caution that doing so could lead to widespread misidentifications.
Instead, ESET advises that defenders and system administrators focus on the protective and detection measures outlined in their security advisories to fortify their systems against these exploitations. Awareness of this newfound vulnerability underscores the ongoing challenges in maintaining safe computing environments in an age where security measures must continually adapt to emerging threats.