ESET finds 11 old UEFI shims bypassing Secure Boot on wide device base

ESET Research has identified 11 Microsoft-signed UEFI shim bootloaders that allow Secure Boot bypass on any system trusting the Microsoft UEFI CA 2011 certificate.

ESET finds 11 old UEFI shims bypassing Secure Boot on wide device base

ESET Research has disclosed the discovery of 11 UEFI shim bootloaders, all carrying valid Microsoft signatures, that can be used to bypass UEFI Secure Boot on a broad range of hardware. The shims, all at version 0.9 or earlier, were found across diagnostic tools, Linux distributions and other UEFI-based utilities. ESET reported the findings to CERT/CC, and Microsoft has since revoked the affected binaries.

The key risk is not a new code-execution flaw but a structural oversight: outdated shims that were signed and legitimately distributed years ago were never revoked, leaving them valid in the eyes of any system that trusts the Microsoft Corporation UEFI CA 2011 certificate authority. An attacker does not need to have the original software installed on a target machine. Carrying a copy of a vulnerable binary to any enrolled system is sufficient to execute untrusted code at boot, before the operating system loads, creating an opening for UEFI bootkit deployment.

The attack surface

Martin Smolár, the ESET researcher who found the shims, described the threat succinctly: "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."

The scope of affected hardware is wide. Because the attack relies on the presence of the Microsoft third-party UEFI certificate, rather than any particular operating system, virtually any UEFI-based device with that certificate enrolled is potentially in scope. Microsoft's Windows 11 Secured-core PCs are expected to ship with third-party UEFI signing disabled by default and are therefore not affected in their default state. All other configurations should be treated as exposed until patches are applied.

Mitigation is available. Windows systems should receive the revocation updates automatically via Windows Update. Linux administrators are directed to the Linux Vendor Firmware Service for the relevant shim updates. ESET also points readers to its earlier research on CVE-2024-7344 for broader guidance on detecting unknown signed UEFI bootloaders and defending against bootkit installation.

Market and regulatory context

The disclosure lands in a period of heightened regulatory attention to firmware security. The EU's NIS2 Directive, which came into force for member states in late 2024, explicitly requires operators of essential services to address vulnerabilities in supply-chain components, including firmware. UEFI-layer threats are particularly pernicious because they persist across operating-system reinstalls and can survive hard-drive replacements, complicating incident response for enterprise security teams.

The broader UEFI shim ecosystem has accumulated technical debt over more than a decade. The upstream shim repository has been updated repeatedly with security hardening, but the Microsoft signing process historically placed the burden of revocation requests on original vendors. Where those vendors no longer maintain the software or have simply stopped tracking upstream releases, signed-but-obsolete binaries can linger in the ecosystem indefinitely.

ESET's finding echoes a pattern seen in previous UEFI disclosures: the root cause is less a novel vulnerability in a single product and more a systemic gap in the lifecycle management of signed firmware components. Security teams should audit which UEFI certificates are enrolled on managed devices and validate that UEFI revocation databases are current, particularly on Linux-based infrastructure where automatic update delivery is less uniform than on Windows fleets.