Microsoft finally patched Secure Boot bypasses that were hiding in plain sight since 2013

Why it matters: A long-standing weakness in a key PC security system stems from a simpler issue: outdated components that were never revoked. Researchers at ESET have found that a set of vulnerable UEFI "shim" bootloaders – some going back to 2013 – remained trusted by Microsoft for years after their flaws were known. As a result, attackers could bypass Secure Boot on both Windows and Linux machines with little difficulty.

The issue affects 11 shim binaries that were still signed and accepted by systems enforcing Secure Boot. That signature is what allows code to run during the boot process. If a trusted component is compromised, everything that follows can be affected.

"What makes these old shims dangerous is not a novel vulnerability," ESET researcher Martin Smolár wrote. "It's that no new vulnerability is needed to bypass UEFI Secure Boot. 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."

In practical terms, an attacker can use one of these shims to load malicious firmware before the operating system even starts. That kind of malware can stick around through OS reinstalls or even hardware changes like replacing a hard drive.

Secure Boot was introduced in 2012 to prevent exactly this type of attack. It works by requiring every piece of code in the boot chain to be signed by a trusted authority. Microsoft serves as a root of trust in the system, signing its own bootloader and the shims used by Linux and other software.

Shims are essentially a workaround that lets non-Microsoft software run in a Secure Boot environment. Once Microsoft signs a shim, it can approve other components using its own embedded certificates.

That setup only works if vulnerable shims are revoked when problems are found. In these cases, that didn't happen.

The affected shims came from a mix of sources, including Linux vendors such as Red Hat, openSUSE, and Oracle, as well as some third-party tools. Some were created before newer protections like SBAT and MOK deny lists existed. Others contain bugs themselves or allow the loading of known vulnerable components.

ESET pointed to one Oracle shim that allows a binary vulnerable to CVE-2015-5381 to run, noting that exploiting it requires relatively little skill.

Part of the problem is how complicated Secure Boot has become. The system relies on multiple layers – trusted signature databases, revocation lists, and newer version-based controls such as SBAT – to determine what can run. Each piece has to be updated and maintained correctly.

"In short, where dbx revokes binaries, SBAT and Microsoft's Secure Boot SVN revoke versions," Smolár explained.

Each boot component includes metadata with a version number, and systems are supposed to block anything older than a defined threshold. But that only works if those thresholds are kept up to date.

Even the expiration of the Microsoft certificate used to sign these shims didn't automatically block them, which highlights how much the system depends on active revocation rather than built-in expiration.

Systems that have installed those updates are no longer vulnerable on Windows, while Linux users are advised to check with their distributions or use tools such as fwupd to confirm they are protected.

The bigger concern is what this says about the system as a whole. Managing trust across so many components, vendors, and updates has proven difficult.

"This is a solid rebuke of the entire secure boot model," HD Moore, CEO and founder of runZero, said in an interview. He argued that too many signed components remain poorly tracked and can still be used in unintended ways. "The end result is a huge number of unknown (to everyone but Microsoft) signed things that bypass Secure Boot – some of which can then be used to boot other things – and both have normal security bugs and other mistakes that mean they can be used to boot nearly anything," Moore added. "The whole ecosystem is somewhat broken and needs a reboot."