Recently, Microsoft finally fixed the Secure Boot (Secure Boot) bypass vulnerability that had been lurking in the system since 2013. Security researchers pointed out that the core problem exposed by this incident was not the vulnerability itself, but the old components with digital signatures but lack of effective tracking management.
This long-standing security vulnerability stems from a simple administrative oversight: obsolete components were never officially revoked. Researchers from well-known security vendor ESET have discovered that a set of vulnerable UEFI "shim" bootloaders, some dating back to 2013, are still considered trusted components by Microsoft systems years after the vulnerabilities were exposed. This means that attackers can effortlessly bypass the secure boot mechanism on Windows and Linux devices. It is reported that the issue involves a total of 11 shim binary files, which still hold valid signatures and are accepted by systems performing secure boot. Since the signature is the key credential that allows code to run during the boot process, once the trusted component is compromised, all subsequent boot steps will be affected.
ESET researcher Martin Smolár emphasized: "The danger of these older versions of shims is not that they employ new vulnerabilities, but that no new vulnerabilities are needed to bypass UEFI Secure Boot. Attackers do not need sophisticated exploits, as long as they have an old but still trusted and unrevoked copy of the shim binary, and have basic knowledge about how the UEFI shim operates, it is enough to bypass this vital security line." In actual attack scenarios, hackers can use these shims to load malicious firmware before the operating system boots. This type of malware is extremely concealed and stubborn, and it is difficult to completely remove it even if you reinstall the operating system or even replace hardware devices such as hard drives.
The secure boot mechanism was first introduced in 2012, and its original intention was to prevent such low-level attacks. This mechanism requires that every piece of code in the launch chain must be digitally signed by a trusted authority. Microsoft serves as the root of trust in the system and is responsible for signing its own boot loader and shims used by other software such as Linux. In fact, shim is a compromise that allows non-Microsoft software to run normally in a secure boot environment. Once Microsoft provides a signature for a shim, the shim can use its embedded certificate to approve subsequent components.
However, the premise for this mechanism to work effectively is that once a shim is found to have a vulnerability, it must be revoked immediately. But in this incident, this blocking mechanism completely failed. Affected shims come from a wide range of sources, covering Linux distributors such as Red Hat, openSUSE and Oracle, as well as some third-party tools. Some of these components existed before the advent of new protection mechanisms such as SBAT and MOK deny lists; others contained code flaws themselves or allowed the loading of components with known vulnerabilities. ESET specifically pointed out an Oracle shim that allows running binaries with CVE-2015-5381 vulnerability, and the technical threshold for exploiting the vulnerability is quite low.
Another part of the problem is the increasing complexity of secure boot mechanisms. The system currently relies on multiple layers to determine which code can run, including a database of trusted signatures, revocation lists, and new version-based mechanisms such as SBAT. Each link requires precise updates and maintenance. As Smolár explains, dbx is responsible for revoking specific binaries, while SBAT and Microsoft's Secure Boot SVN are responsible for revoking specific versions. Each startup component contains metadata with a version number, and the system is supposed to intercept any component that falls below a set threshold. But this completely relies on the timely updating of threshold data. It is worth noting that even if the Microsoft certificate used to sign these shims expires, it does not automatically prevent them from running, which fully exposes the entire system's reliance on active revocation rather than built-in expiration failure mechanisms.
Currently, Windows systems that have installed the latest updates are no longer threatened by this vulnerability; for Linux users, experts recommend checking with the corresponding distribution official, or using tools such as fwupd to confirm whether the system has been protected.
However, what arouses deeper concerns in the industry is the fragile status of this trust system. Managing trust relationships across numerous components, vendors, and frequent updates has proven to be an extremely difficult task. HD Moore, CEO and founder of runZero, said bluntly in an interview: "This is a severe criticism of the entire secure boot model." He pointed out that there are too many signed components that lack effective tracking and can still be used for unintended and dangerous purposes. Moore concluded: "The end result is that there are a large number of signed components (known to no one except Microsoft) that can bypass Secure Boot - some of which are used to boot other programs, and they also carry general security holes and other bugs, which means that they can be used to boot almost anything. The entire ecosystem is broken to some extent and needs a complete reboot."