Cybersecurity researchers have discovered 11 old, Microsoft-signed, Unified Extensible Firmware Interface (UEFI) applications that could be abused to bypass Secure Boot on most systems using the modern firmware standard.
“An attacker exploiting one of these vulnerable applications can execute untrusted code during system boot, enabling deployment of malicious UEFI bootkits or other malware,” ESET researcher Martin Smolár said in a report published today.
The UEFI shim bootloaders expose any UEFI-based machine that trusts Microsoft’s “Microsoft Corporation UEFI CA 2011” third-party UEFI certificate authority (CA) certificate, irrespective of the installed operating system. The certificate is used to sign third-party boot components intended to run under Secure Boot. It expired as of June 27, 2026, and has been replaced by Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023.
The shim is a lightweight, open-source UEFI bootloader that acts as an intermediary between a computer’s motherboard firmware and the Linux operating system. Its primary purpose is to allow Linux distributions to boot when Secure Boot is enabled. It’s worth noting that the shim itself is signed with a key trusted by the firmware, mostly a Microsoft signature, as its certificates come pre-installed on UEFI-based devices.
The sequence proceeds like this: the UEFI firmware loads the shim and validates its signature against the Microsoft CA stored in the firmware. The shim then validates the second-stage bootloader (in most cases, GRUB 2) against its own embedded vendor certificate. GRUB 2 finally validates the kernel using the same vendor certificate.
The Slovak cybersecurity company said the outdated-but-trusted shims can be exploited to execute arbitrary code when the system boots up, allowing bad actors to deploy UEFI bootkits like Bootkitty, HybridPetya, or BlackLotus even when Secure Boot protections are enabled.
The UEFI bootloaders of the open-source shim project, mainly from version 0.9 and earlier, have since been revoked by Microsoft as part of its June 2026 Patch Tuesday update following responsible disclosure earlier this February. The list of the impacted shim bootloaders is below –
- Spyrus WTGCreator from UEFI shim loader (0.7 or lower)
- RedHat RedHat Enterprise Linux (7.2) from UEFI shim loader (0.9)
- RedHat CentOS (7.2) from UEFI shim loader (0.9)
- Baramundi software baramundi Management Suite (up to 2024R1) from UEFI shim loader (0.8)
- WhiteCanyon/Blancco WipeDrive (8.0.0 through 8.1.3) from UEFI shim loader (0.7)
- Finland’s Matriculation Examination Board Abitti 1 (1.0) from UEFI shim loader (0.8)
- NTC IT ROSA, LLC ROSA Linux (R10, R9) from UEFI shim loader (0.9)
- Oracle America, Inc. OracleLinux (7.2) from UEFI shim loader (0.9)
- PC-Doctor, Inc. PC Doctor Service Center (15, 16) from UEFI shim loader (0.9)
- OpenSuse OpenSuse UEFI Shim loader (0.9)
- OpenSuse OpenSuse Shim (2.1) from UEFI Shim loader (0.9)
A consequence of this loophole is that an attacker could exploit these susceptible shim bootloaders to bypass newer security mechanisms by making use of the bring your own vulnerable driver (BYOVD) attack technique to run arbitrary code during the early boot phase, even before the operating system is initialized.
Linux systems also come with a security feature called a Machine Owner Key (MOK) allowlist that lets users authorize unsigned drivers to be loaded while UEFI Secure Boot is active. Although a MOK denylist was introduced in shim version 0.9 as a way to revoke old signing certificates associated with a vulnerable UEFI binary and re-sign patched versions.
In this context, an attacker could replace the victim’s up-to-date shim with an older Microsoft-signed UEFI shim and bypass MOK denylist enforcement by taking advantage of the fact that the allowlist still trusts the old certificate. This, in turn, could allow an attacker’s shim to load vulnerable binaries without restriction and obtain arbitrary code execution.
That’s not all. The attack also subverts Secure Boot Advanced Targeting (SBAT), which is designed to revoke vulnerable boot components as opposed to maintaining a huge blocklist of individual cryptographic hashes corresponding to each file. Put differently, the mechanism is used to update the minimum acceptable generation whenever a vulnerability is discovered in a boot chain component. If an attempted boot uses an older, vulnerable version, the system blocks it and throws an error.
The CERT Coordination Center (CERT/CC), in an advisory issued last month, said the vendor-specific bootloaders have not been updated to address vulnerabilities in the upstream project after they became publicly known and fixed.
“As a result, vulnerable bootloaders remained signed and trusted by Secure Boot systems because they had not been revoked through the Microsoft-signed DBX revocation list,” it noted. “This created a long-term supply chain exposure in which outdated and vulnerable boot components could still be executed on fully patched systems.”
The result is that an attacker with administrative privileges or the ability to modify the boot process could abuse one of the above vulnerable shim bootloaders to bypass Secure Boot protections and execute arbitrary code before the operating system loads, paving the way for entrenched persistence that can survive operating system reboots and, in a few cases, its reinstallation.
Because all this occurs before the operating system and security products are initialized, malicious code executed through the bootloaders can also sidestep detection by built-in security controls and endpoint detection and response (EDR) solutions.
The issues are tracked under the CVE identifiers CVE-2026-8863 and CVE-2026-10797, with the latter referring to a long-patched issue in shim that allowed the certificate-based revocation mechanism to be bypassed by modifying the second-stage bootloader’s signature header.
ESET has warned that the expiration of the “Microsoft Corporation UEFI CA 2011” certificate has no bearing on the Secure Boot verification process as long as the bootloaders signed with the expired certificate are not explicitly revoked by hash.
“What makes these old shims dangerous is not a novel vulnerability, it’s that no new vulnerability is needed to bypass UEFI Secure Boot,” ESET said. “An attacker needs no complicated exploitation primitives – only a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims work. That is enough to bypass such an essential security feature as UEFI Secure Boot.”
