Cybersecurity researchers have uncovered a blind spot in Secure Boot, a security feature designed to prevent malware from launching at startup. For years, nearly a dozen vulnerable but still trusted UEFI shim bootloaders remained on systems, allowing attackers to bypass Secure Boot protections and execute malicious code at boot time.
The discovery was made by ESET, which reported the findings to Microsoft in June. The company subsequently revoked the vulnerable bootloaders through Secure Boot revocation updates. However, unpatched systems may continue to trust these components, leaving them exposed to boot-level attacks.
So, what are UEFI shim bootloaders? In simple terms, they’re small programs that act as a bridge between the firmware and operating system bootloader on Secure Boot-enabled systems. They allow Linux distributions to boot on Secure Boot-enabled UEFI systems by verifying and launching the rest of the Linux boot process. Think of them like a trusted messenger who ensures the operating system can start up safely.
The 11 vulnerable shim bootloaders discovered by ESET were versions 0.9 or earlier, which is several generations behind current versions. These older shims either launched vulnerable second-stage bootloaders or lacked security protections available in newer versions. In some cases, they even contained vulnerabilities that could allow attackers to bypass Secure Boot protections.
The issue affects all UEFI systems with Microsoft third-party UEFI signing enabled, although the option is typically disabled by default on Windows 11 Secured-core PCs. An attacker only needs a copy of one of these old bootloaders and an understanding of how Secure Boot works to bypass the secure startup process. This highlights a critical flaw in the way trust is managed in the Secure Boot chain.
The ESET discovery has sparked concerns about the challenge of preventing old and vulnerable software from remaining trusted components long after they’re no longer reliable. “This is not merely a flaw in 11 obscure products,” says Jason Soroko, senior fellow at Sectigo. “It’s a failure to retire trust.” Microsoft’s June revocations prevent systems with updated Secure Boot deny lists from trusting the known vulnerable shims, but older shims signed before 2017 may be more difficult to identify and revoke.
The broader lesson here is that signed boot code can become long-lived ‘Secure Boot debt’ when inventory and revocation lag behind software retirement. This highlights the importance of regularly reviewing and updating trust relationships in Secure Boot chains. System administrators should prioritize keeping their systems up-to-date with the latest Secure Boot updates, including revoking any vulnerable components.
As a user, it’s essential to be aware of these security risks and take steps to protect your system. If you’re running a UEFI system, ensure that Microsoft third-party UEFI signing is disabled unless absolutely necessary. Also, keep an eye on firmware updates and patch levels for your system, especially when it comes to Secure Boot components. By staying vigilant and proactive, you can help prevent these types of vulnerabilities from affecting your security posture.
Source: Dark Reading — 2026-07-15