Secure Boot’s Decade-Long Blind Spot
A failure to revoke 11 vulnerable UEFI shims has left Windows and Linux systems open to persistent firmware-level exploitation.
For 13 of the 14 years since its inception, the security architecture intended to protect the boot process of modern computers has been fundamentally undermined by a simple oversight. Researchers at ESET discovered that 11 shims—digitally signed by Microsoft—remained valid despite containing known defects, creating a trivial pathway for attackers to bypass the UEFI Secure Boot mechanism.
The Anatomy of a Persistent Failure
Secure Boot was introduced in 2012 to defend against bootkits, a class of malware that compromises a computer’s firmware to maintain persistence even after an operating system is reinstalled or hardware is replaced. The current vulnerability does not rely on sophisticated code or novel exploitation primitives. Instead, it leverages forgotten, unrevoked shim binaries that Microsoft failed to place on the revocation list. Because these files remain digitally signed by a trusted authority, they can be utilized by unauthorized parties to subvert the boot sequence.
These shims were originally designed to bridge the gap between Secure Boot and Linux distributions or utility software. However, their continued existence in a trusted state allows a malicious actor to load compromised firmware early in the boot process, effectively rendering the device's primary security layer useless. While previous high-profile threats like LoJax, MosaicRegressor, CosmicStrand, and BlackLotus demonstrated the danger of bootkits, this oversight turns the very infrastructure meant to stop such attacks into a tool for them.
The Complexity Barrier
The failure to manage these revocations stems from the extreme technical complexity of the Secure Boot ecosystem. Microsoft manages trust through two primary databases, but the limited space available in the dbx revocation database makes it difficult to track every compromised component individually. Consequently, the industry has shifted toward methods like SBAT, which relies on version numbers rather than individual file hashes to mitigate risks.
“What makes these old shims dangerous is not a novel vulnerability. 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.”
— Martin Smolár, ESET researcher
As explained in this section of the research, these version-based checks are intended to prevent outdated, vulnerable binaries from executing. However, the system relies on the assumption that vendors and Microsoft consistently maintain the integrity of the revocation chain, an assumption that proved incorrect for these 11 files.
Technical Scope of the Flaw
- 11 vulnerable firmware images identified as defective.
- 13 years of existence for the broken security state.
- 32kb of space allocated to the dbx revocation database.
- 1 vulnerability linked to CVE-2015-5381 found in an Oracle shim.
Consequences for the Ecosystem
The implications of this discovery extend beyond a single patch cycle. The fact that an industry-standard security measure could be bypassed for over a decade via basic scripts suggests deep structural issues in how UEFI trust is managed. For businesses and individual users, this necessitates immediate attention; those who have not applied the updates released by Microsoft in June remain potentially susceptible. Furthermore, the situation highlights the fragility of relying on a centralized root of trust in an ecosystem with such high variance in firmware implementation. As long as the burden of maintenance remains siloed within complex, opaque signing processes, the risk of similar “forgotten” vulnerabilities remains a persistent threat to the integrity of the hardware supply chain.
