Secure Boot, normally an impenetrable barrier to booting modern machines, has just revealed a long-standing vulnerability. Eleven UEFI shims signed by Microsoft, but never revoked, allow users to bypass this system. The threat extends beyond Windows and Linux and affects almost all PCs that trust the 2011 certificate.
These bootloaders, inherited from older versions, are still accepted by UEFI firmware. Copying one of these binaries to the EFI partition is enough to bypass Secure Boot verification. Let’s examine what you need to know to understand and counter this vulnerability.
This security issue casts doubt on the trust placed in the well-known “Microsoft Corporation UEFI CA 2011 certificate.” The crucial startup monitoring has been compromised by a persistent oversight.
Why are these UEFI shims a major risk to Secure Boot in 2026?
Secure Boot relies on verifying each component loaded during startup using lists: db (authorized) and dbx (revoked). Microsoft signs the shims with its certificate, which is embedded in db by most manufacturers. So far, so good.
The catch: a shim is signed once and ensures the chain of trust to subsequent components, such as GRUB2 or the Linux kernel, avoiding the need for Microsoft to sign each update. Clever, but a double-edged sword!
The problem, revealed by researcher Martin Smolár via ESET, is that 11 old shims have never been revoked in dbx. This inaction makes the attack simple but effective: any machine accepting the 2011 certificate remains vulnerable.
Shims signed years ago, never disavowed
These bootloaders all predate version 1.0 (0.7 to 0.9) and are associated with various solutions. Among the vulnerable are commercial Linux distributions such as Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, and ROSA Linux. Two older openSUSE binaries are also affected.
Other software, such as PC-Doctor Service Center, baramundi Management Suite, Abitti for the Finnish education system, as well as WipeDrive and Spyrus WTGCreator, are also on this list. All share this obsolete signature, which has never been invalidated.
Copying a signed shim onto the EFI boot partition is the technical equivalent of inserting a master key into the lock, bypassing any high-performance protection installed downstream.
How do these old shims allow Secure Boot to be bypassed?
The main problem is that no new malicious code is needed. It’s simply a matter of copying and pasting a genuine shim previously signed by Microsoft. Regardless of the target, Windows or Linux, the chain of trust accepts them as legitimate.
For an attacker to exploit the vulnerability, privileged access to the machine is indeed required. But persistence then becomes very easy, as they can deploy the malicious shim without the UEFI reacting.
The analogy with BYOVD (Bring Your Own Vulnerable Driver) is apt here. The trust placed in the shim becomes the weak link that can be exploited through this method.
Specific cases illustrate the impact of obsolete shims.
The Oracle Linux 7.2 shim, for example, allows a GRUB 2 version of the Oracle Linux 7.1 ISO, which is affected by CVE-2015-5281. This allows arbitrary code execution without thorough verification. There’s no need to exploit memory corruption.
Abitti 0.8 copies a shim that ignores MokListX, the revocation list integrated into version 0.9, providing another attack vector. Red Hat Enterprise Linux 7.2 uses a shim predating version 15.3 (the introduction of SBAT), so it doesn’t check the SbatLevel policy and loads revoked images without hesitation.
These are all examples where the supposedly inviolable chain of trust cracks without heroic effort, simply because of a forgotten component.
The main recommendation is to apply Microsoft’s latest UEFI revocation lists, distributed since June 2026. These updates correct the dbx database to designate these old signed shims as unwanted.
On Windows, these updates are primarily delivered via Windows Update. A small PowerShell script, provided by ESET, can be used to verify that the revocations have been correctly applied. A simple check using the hashes of the faulty shims confirms the system’s status.
For Linux, database updates are handled by the Linux Vendor Firmware Service. The uefi-dbx-audit script will audit the local system. It is recommended to update the database before applying DBX revocations to avoid any inconsistencies.
A matter of vigilance and updating
This issue demonstrates that startup security relies not only on certificate validity but also on rigorously revoking obsolete components. The expiration of the Microsoft certificate in June 2026 is irrelevant if the revocation is not effective.
ESET’s report highlights that several serious threats, such as the BlackLotus and Bootkitty bootkits, could exploit this vector. Prevention is not optional; it is vital for critical infrastructure.
Thinking that Secure Boot is invulnerable is to expose yourself. When it comes to security, it’s better to be like a good farmer: anticipate the holes in the fence before the wolf gets through.