11 Linux Signed by Microsoft UEFI Shims Could Let Attackers Bypass Secure Boot

Cybersecurity researchers found 11 old, Microsoft-signed, Unified Extensible Firmware Interface (UEFI) applications that could be exploited to bypass Secure Boot on many systems using the modern firmware standard.

“An attacker using one of these vulnerable applications could execute untrusted code during system startup, allowing the deployment of malicious UEFI bootkits or other malware,” said ESET researcher Martin Smolár in a report published today.

The UEFI shim loaders expose any UEFI-based machine that trusts the Microsoft “Microsoft Corporation UEFI CA 2011” certificate from a third-party UEFI certificate authority (CA), regardless of the installed operating system. The certificate is used to sign third-party boot components intended to run under Secure Boot. Expired as of June 27, 2026, and 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 main purpose is to allow Linux distributions to boot when Secure Boot is enabled. It is worth noting that the shim itself is signed with a key trusted by the firmware, specifically Microsoft’s signature, as its certificates come pre-installed on UEFI-based devices.

The sequence goes like this: the UEFI firmware loads the shim and verifies its signature against the Microsoft CA stored in the firmware. The shim then verifies the second-tier bootloader (in most cases, GRUB 2) against its embedded vendor certificate. GRUB 2 finally verifies the kernel using the same vendor certificate.

The Slovakian cybersecurity firm said outdated but trusted shims can be used to execute malicious code at system startup, allowing bad actors to launch UEFI bootkits like Bootkitty, HybridPetya, or BlackLotus even when Secure Boot protection is enabled.

The open source shim project’s UEFI bootloaders, especially in version 0.9 and earlier, have since been withdrawn by Microsoft as part of the June 2026 Patch Tuesday update following a proper disclosure earlier this February. The list of affected 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 baramundi Management Suite software (up to 2024R1) from UEFI shim loader (0.8)
• WhiteCanyon/Blanco WipeDrive (8.0.0 to 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)

The result of this hack is that an attacker can use these vulnerable shim loaders to bypass the new security measures by using your own vulnerable driver (BYOVD) attack method to execute arbitrary code during the initial boot phase, even before the application is launched.

Linux systems also come with a security feature called Machine Owner Permission List (MOK) that allows users to authorize unregistered drivers to be loaded while UEFI Secure Boot is running. Although the MOK denial list was introduced in shim version 0.9 as a way to revoke old signing certificates related to the UEFI binary vulnerability and to re-sign deprecated versions.

In this context, an attacker can replace the victim’s latest shim with an old UEFI shim signed by Microsoft and bypass the use of the MOK denial list by taking advantage of the whitelist still trusting the old certificate. This, in turn, may allow an attacker shim to load vulnerable binaries unfettered and gain arbitrary code execution.

It doesn’t end there. This attack also disrupts Secure Boot Advanced Targeting (SBAT), which is designed to intercept vulnerable boot components by counter-maintaining a large list of cryptographic hashes associated with each file. Put differently, the method is used to update the minimum acceptable generation whenever a vulnerability is detected in a part of the boot chain. If the boot attempt 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 that vendor-specific bootloaders have not been updated to address vulnerabilities in the upstream project after they were publicly known and fixed.

“As a result, vulnerable bootloaders remain signed and trusted by Secure Boot systems because they have not been revoked through the DBX revocation list signed by Microsoft,” it noted. “This has created long-term supply chain exposure where outdated and vulnerable boot components can still be used in fully patched systems.”

The result is that an attacker with administrative privileges or the ability to modify the boot process can abuse one of the above vulnerable shim loaders to bypass Secure Boot protections and execute malicious code before the operating system is loaded, paving the way for persistent rooting that can survive operating system restarts and, in a few cases, reinstallation.

Because all of this happens before the application and security products are launched, malicious code released via downloaders can bypass detection by built-in security controls and detection and response (EDR) solutions.

The issues are tracked under the identifiers CVE-2026-8863 and CVE-2026-10797, the latter of which refers to a long-patched issue that allows the certificate-based revocation method to be bypassed by changing the signature header of the second-tier bootloader.

ESET has warned that the expiration of the “Microsoft Corporation UEFI CA 2011” certificate does not affect the Secure Boot authentication process as long as bootloaders signed with the expired certificate cannot be clearly hashed.

“What makes these old cheats dangerous isn’t that they’re new vulnerabilities, it’s that no new vulnerability is needed to bypass UEFI Secure Boot,” ESET said. “An attacker doesn’t need sophisticated exploit primers – just a copy of an old, trusted, but not revoked binary shim and a basic understanding of how UEFI works. That’s enough to bypass an important security feature like UEFI Secure Boot.”