# Forgotten UEFI Shims Expose Secure Boot Bypass Vulnerabilities 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** stated in a recent report. ## The Lingering Threat of Outdated Shims 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, regardless of the installed operating system. This certificate, which expired on June 27, 2026, and has since been replaced by **Microsoft UEFI CA 2023** and **Microsoft Option ROM UEFI CA 2023**, is crucial for signing third-party boot components intended to run under **Secure Boot**. The shim itself is a lightweight, open-source **UEFI** bootloader that acts as an intermediary, allowing **Linux** distributions to boot when **Secure Boot** is enabled. It's signed with a key trusted by the firmware, typically a **Microsoft** signature, as its certificates come pre-installed on **UEFI**-based devices. The boot sequence generally proceeds as follows: 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 (often **GRUB 2**) against its own embedded vendor certificate, which in turn validates the kernel. **ESET** warns that these outdated-but-trusted shims can be exploited to execute arbitrary code during system boot, enabling threat actors to deploy **UEFI** bootkits like **Bootkitty**, **HybridPetya**, or **BlackLotus**, even when **Secure Boot** protections are active. ## Revocation and Persistent Vulnerabilities **Microsoft** has since revoked the **UEFI** bootloaders of the open-source shim project, primarily from version 0.9 and earlier, as part of its June 2026 Patch Tuesday update. This action followed responsible disclosure earlier in February. The list of impacted shim bootloaders includes: * **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) ## Bypassing Advanced Security Measures This loophole enables an attacker to exploit these susceptible shim bootloaders using the bring your own vulnerable driver (**BYOVD**) attack technique. This allows for arbitrary code execution during the early boot phase, even before the operating system initializes, bypassing newer security mechanisms. **Linux** systems incorporate a **Machine Owner Key (MOK)** allowlist, which permits users to authorize unsigned drivers to load while **UEFI Secure Boot** is active. Although a **MOK** denylist was introduced in shim version 0.9 to revoke old signing certificates and allow re-signing of patched versions, an attacker could replace an up-to-date shim with an older, **Microsoft**-signed **UEFI** shim. This bypasses **MOK** denylist enforcement by leveraging the fact that the allowlist still trusts the old certificate, allowing the attacker's shim to load vulnerable binaries without restriction and achieve arbitrary code execution. The attack also undermines **Secure Boot Advanced Targeting (SBAT)**, a mechanism designed to revoke vulnerable boot components by updating the minimum acceptable generation when a vulnerability is discovered. If an older, vulnerable version is used, the system should block it. However, the **CERT Coordination Center (CERT/CC)** noted in an advisory that vendor-specific bootloaders were not updated to address known vulnerabilities. "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," **CERT/CC** stated. "This created a long-term supply chain exposure in which outdated and vulnerable boot components could still be executed on fully patched systems." ## The Impact: Persistent Code Execution An attacker with administrative privileges or the ability to modify the boot process could exploit these vulnerable shim bootloaders to bypass **Secure Boot** protections and execute arbitrary code before the operating system loads. This paves the way for entrenched persistence that can survive operating system reboots and, in some cases, reinstallation. Crucially, because this occurs before the operating system and security products are initialized, malicious code executed through these bootloaders can evade detection by built-in security controls and **Endpoint Detection and Response (EDR)** solutions. These issues are tracked under the **CVE** identifiers **CVE-2026-8863** and **CVE-2026-10797**. The latter refers 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 cautioned 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** concluded. "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**."