Linux UEFI Shim Vulnerability Severe Exploitation of Obsolete Bootloaders

While two CVE IDs were assigned to this case, CVE-2026-8863 and CVE-2026-10797, exploitation of each reported shim is not just about a single bug that can be found in these old shims directly. In fact, the attack surface is extended by the shims’ trusted, second-stage bootloaders—most notably GRUB 2—which, like the shims themselves, often include outdated versions with known vulnerabilities. The discovered shims come from various software packages, including PC-diagnostics utilities and older Linux distributions. Importantly, exploitation is not limited to systems with the affected software installed, as attackers can bring their own copy of these vulnerable, Microsoft-signed shims to any UEFI system with the Microsoft third-party certificate enrolled.

The Problem of "Secure Boot Debt"

This is not merely a collection of 11 vulnerable binaries; it is a textbook case of "Secure Boot debt"—the accumulation of old, trusted code that creates a persistent attack surface. To allow Linux distributions to boot on Secure Boot-enabled systems without Microsoft signing every distribution-specific bootloader, the open-source shim project provides a small first-stage bootloader that Microsoft signs once. This shim acts as a secondary anchor, verifying and launching the rest of the boot stack.

The breakdown occurs here: these shims do not have an expiration date. In the eyes of the firmware, a shim signed in 2013 is often just as "valid" as one signed in 2026. Because these legacy shims predate security features like Secure Boot Advanced Targeting (SBAT), which embeds generation metadata into boot components to allow entire vulnerable generations to be revoked, they simply ignore current revocation policies.

Risk and Persistence

It is vital to note that this is primarily a persistence mechanism rather than a remote, "one-click" initial access vector. Exploitation generally requires an attacker to already possess significant privileges or control over the boot process, such as administrative access, physical access to the machine, or a successful compromise of the host OS. Once a vulnerable shim is utilized, however, the malicious code operates from a position of authority, establishing persistence that survives OS reinstalls and disk wipes. Since this exploit occurs before the OS loads, many OS-level security controls, including EDR agents, cannot observe the initial compromise.

Strengthening the Chain

The primary obstacle to revocation is the scale of ecosystem coordination. While newer mechanisms like SBAT are critical for scalability, systems running bootloaders from a decade ago do not know how to verify those policies. To protect systems, administrators should prioritize the following:

• Prioritize the dbx Update: Ensure all systems have applied the latest Secure Boot revocation list updates. This is the primary defense against the execution of these specific binaries.
• Audit Firmware Lifecycle: Firmware-level auditing must be incorporated into standard vulnerability management. Treat bootloader inventory with the same scrutiny applied to OS-level package managers.
• Retire Legacy Components: Periodically inventory the boot chain and remove obsolete shim and GRUB binaries from deployment images. Old, signed components should not remain available simply because they still boot successfully.

The BootHole disclosure demonstrated that Secure Boot depends on every trusted component in the boot chain.

Secure Boot Is Only as Strong as Its Trust Chain

Secure Boot isn't a security feature that you can "set it and forget it"; it's a trust model that needs to be maintained all the time. Updating the operating system is only half the battle if old boot components are still trusted below it. Linux administrators can lower Secure Boot debt and protect the boot chain's integrity by regularly applying Secure Boot revocation updates, getting rid of old shim and GRUB binaries, and including firmware in regular security maintenance.