11 Vulnerable Microsoft-Signed UEFI Shims Risk Bypassing Secure Boot

Cybersecurity researchers have identified 11 outdated, Microsoft-signed Unified Extensible Firmware Interface (UEFI) applications that pose a significant risk by potentially allowing attackers to bypass Secure Boot on systems utilizing modern firmware standards. This vulnerability highlights critical weaknesses in the UEFI boot process, which could enable the execution of untrusted code during system startup.

ESET researcher Martin Smolár emphasized the severity of the situation, stating that “an attacker exploiting one of these vulnerable applications can execute untrusted code during system boot, enabling deployment of malicious UEFI bootkits or other malware.” This revelation raises alarms about the integrity of systems that rely on Secure Boot for protection against unauthorized code execution.

Understanding UEFI and Secure Boot

The UEFI shim bootloaders are particularly concerning because they expose any UEFI-based machine that trusts Microsoft’s “Microsoft Corporation UEFI CA 2011” third-party UEFI certificate authority (CA) certificate. This certificate, which is used to sign third-party boot components intended to operate under Secure Boot, expired on June 27, 2026. It has since been replaced by the Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023.

The shim serves as a lightweight, open-source UEFI bootloader that acts as an intermediary between a computer’s motherboard firmware and the Linux operating system. Its primary function is to facilitate the booting of Linux distributions when Secure Boot is enabled. Notably, the shim itself is signed with a key trusted by the firmware, predominantly a Microsoft signature, as its certificates are pre-installed on UEFI-based devices.

The boot process involves several steps: 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, typically GRUB 2, against its own embedded vendor certificate. Finally, GRUB 2 validates the kernel using the same vendor certificate.

Exploitation of Vulnerable Shims

The outdated shims can be exploited to execute arbitrary code during system boot, allowing malicious actors to deploy UEFI bootkits such as Bootkitty, HybridPetya, or BlackLotus, even when Secure Boot protections are active. Microsoft has since revoked the UEFI bootloaders of the open-source shim project, particularly those from version 0.9 and earlier, as part of its June 2026 Patch Tuesday update, following responsible disclosure earlier in February.

The list of impacted shim bootloaders includes:

• Spyrus WTGCreator from UEFI shim loader (0.7 or lower)
• RedHat Enterprise Linux (7.2) from UEFI shim loader (0.9)
• RedHat CentOS (7.2) from UEFI shim loader (0.9)
• 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 Linux (7.2) from UEFI shim loader (0.9)
• PC Doctor Service Center (15, 16) from UEFI shim loader (0.9)
• OpenSuse UEFI Shim loader (0.9)
• OpenSuse Shim (2.1) from UEFI Shim loader (0.9)

This vulnerability allows attackers to exploit these susceptible shim bootloaders to bypass newer security mechanisms using the bring your own vulnerable driver (BYOVD) attack technique. This enables them to run arbitrary code during the early boot phase, even before the operating system is initialized.

Machine Owner Key (MOK) Allowlist and Denylist

Linux systems incorporate a security feature known as a Machine Owner Key (MOK) allowlist, which permits users to authorize unsigned drivers to be loaded while UEFI Secure Boot is active. A MOK denylist was introduced in shim version 0.9 to revoke old signing certificates associated with vulnerable UEFI binaries and re-sign patched versions.

In this scenario, an attacker could replace the victim’s up-to-date shim with an older Microsoft-signed UEFI shim, circumventing MOK denylist enforcement. This exploitation occurs because the allowlist still trusts the old certificate, enabling the attacker’s shim to load vulnerable binaries without restriction and achieve arbitrary code execution.

Moreover, this attack undermines Secure Boot Advanced Targeting (SBAT), which is designed to revoke vulnerable boot components rather than maintain an extensive blocklist of individual cryptographic hashes corresponding to each file. SBAT aims to update the minimum acceptable generation whenever a vulnerability is discovered in a boot chain component. If an attempt is made to boot using an older, vulnerable version, the system should block it and generate an error.

The CERT Coordination Center (CERT/CC) issued an advisory indicating that vendor-specific bootloaders had not been updated to address vulnerabilities in the upstream project after they became publicly known and fixed. Vulnerable bootloaders remained signed and trusted by Secure Boot systems because they had not been revoked through the Microsoft-signed DBX revocation list. This situation has created a long-term supply chain exposure, allowing outdated and vulnerable boot components to be executed on fully patched systems.

Implications for Security

The consequences of this vulnerability are significant. An attacker with administrative privileges or the ability to modify the boot process could exploit one of the vulnerable shim bootloaders to bypass Secure Boot protections and execute arbitrary code before the operating system loads. This could lead to persistent threats that survive operating system reboots and, in some cases, reinstallation.

Since all of this occurs before the operating system and security products are initialized, malicious code executed through the bootloaders can evade detection by built-in security controls and endpoint detection and response (EDR) solutions.

The vulnerabilities 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 cautioned that the expiration of the “Microsoft Corporation UEFI CA 2011” certificate does not affect the Secure Boot verification process as long as the bootloaders signed with the expired certificate are not explicitly revoked by hash. The danger posed by these old shims lies not in a new vulnerability but in the fact that no new vulnerabilities are needed to bypass UEFI Secure Boot. An attacker requires only a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims operate to circumvent this essential security feature.

Source: thehackernews.com

Keep reading for the latest cybersecurity developments, threat intelligence and breaking updates from across the Middle East.