Microsoft Secure Boot Vulnerable for 13 Years

Based on an article by Dan Goodin at Ars Technica, researchers from ESET have uncovered a vulnerability that has allowed Microsoft’s Secure Boot to be bypassed for 13 years. This means the feature has been effectively rendered powerless for most of its existence since its introduction in 2009.

“What makes these old shims dangerous is not a novel vulnerability,” ESET researcher Martin Smolár wrote Tuesday. “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.”

The core issue lies with UEFI bootloader files known as “shims.” These shims were designed as part of a Microsoft-signed system to enable Linux distributions and utility software to utilize Secure Boot. However, ESET discovered that at least 11 shim binaries, including some dating back to 2013, have not been revoked by Microsoft despite their vulnerabilities being identified. These files remain signed and publicly accessible.

Attackers can exploit these outdated shim files to compromise the chain of trust required by Secure Boot. This method allows them to embed malware into the early stages of the boot process, enabling the installation of bootkits that persist even after the operating system is reinstalled or the hard drive is replaced. As Smolár noted, bypassing this security measure does not require advanced exploitation techniques, meaning even entry-level hackers can execute it with relatively simple procedures.

11 Unrevoked Shims and Their Impact

According to a list compiled by CERT, among the 11 unreleased shims, some were used by Linux distributors like Red Hat, openSUSE, and Oracle. Others were included in third-party software from entities such as Finland’s Matriculation Examination Board and PC-Doctor. Many of these shims were built before the advent of protective mechanisms like SBAT (Secure Boot Advanced Targeting) or MOK (Machine Owner Key) denial lists. Additionally, some of the code or the second-stage binaries authenticated by the shims contain cumulative bugs.

This vulnerability affects both Windows and Linux users, as the shims can be installed on systems running either OS. Once the boot process is compromised, the malware can persist regardless of the operating system type. Because the malware survives even after a drive replacement, it becomes challenging to eradicate through system reinstallation.

By bypassing Secure Boot, attackers can deploy bootkits, which are malicious firmware designed to survive system resets. Previous examples of bootkits include LoJax, used by Russian state-sponsored hackers in 2018, MosaicRegressor in 2020, CosmicStrand in 2022, and BlackLotus in 2023. ESET has also tracked several other bootkits, including ESpecter, FinSpy, and MoonBounce.

Threat Model and Attack Scenarios

Secure Boot was introduced in 2012 to mitigate the risk of bootkits by ensuring only signed code runs during the boot process. If attackers gain physical access to a device, they can install bootkits even when the device is powered off. Secure Boot is specifically designed to defend against such threats.

This vulnerability significantly increases the risk posed by attackers with physical access to devices. However, not all bootkits require physical access, as remote methods of interfering with the boot process also exist, potentially broadening the scope of the threat.

Microsoft, responsible for the signature management of shims, failed to revoke shims with known vulnerabilities. This lack of governance has directly contributed to a 13-year-long security vulnerability.

Editorial Opinion

In the short term, the widespread awareness of this vulnerability will likely compel Microsoft to quickly add all 11 affected shims to its revocation list. At the same time, impacted Linux distributors and third-party vendors must strengthen their products’ defenses by updating SBAT and MOK denial lists. Corporate security teams should urgently audit systems to identify and eliminate vulnerable shims. This is especially crucial in remote work environments where physical device management is challenging, increasing the risk of exploitation of this vulnerability.

In the long term, this issue highlights a fundamental problem in software supply chain management. It raises questions about how platform vendors with signing authority should audit and determine the expiration timeline for previously signed binaries. Since Secure Boot relies on a “chain of trust,” maintaining this chain inevitably demands ongoing operational costs. This is not just a Microsoft issue but a challenge shared by other platform vendors like Google and Apple.

References

• “Microsoft’s Secure Boot has been broken for a decade and no one noticed until now”, by Dan Goodin — Ars Technica, 2026-07-14T22:20:48.000Z (CC BY-NC-ND)
• Source URL: https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/