A Security Standard Built on a Forgotten Flaw
Security researchers at ESET have confirmed that Secure Boot – the firmware protection standard Microsoft invented and has administered for 14 years – was effectively bypassable for 13 of those years, and nobody caught it.
What Secure Boot Was Supposed to Do
Secure Boot was designed to stop malicious software from burrowing into a device’s firmware before its operating system even loads. It works through the UEFI – the Unified Extensible Firmware Interface – embedded in a device’s motherboard, and it enforces a chain of digitally signed software at every stage of the startup process. If anything in that chain can’t be verified, the system halts. That’s the theory, anyway.
The protection was extended to Linux devices and certain utility software through a mechanism called a shim – a small piece of signed code that acts as a bridge between UEFI and software Microsoft’s signing process wouldn’t normally cover. Shims were a practical solution to a real compatibility problem, and they became a standard part of the Linux boot ecosystem.
The flaw ESET identified isn’t in the concept. It’s in the maintenance, or the near-total absence of it.
ESET found 11 firmware images – at least one dating back to 2013 – that were known to contain vulnerabilities but were never revoked by Microsoft. These shims remained publicly available and still carry valid Microsoft signatures. Because Microsoft controls the shim-signing process, the responsibility for pulling defective images from circulation sat with the company. For over a decade, that didn’t happen.
How Easy Is the Attack, and Who’s at Risk
The practical consequence is that any of these 11 old, unrevoked shims can be used to completely sidestep Secure Boot. The technique required to do this is simple enough that novice-level attackers – not sophisticated nation-state operators – could execute it. That distinction matters when estimating real-world threat exposure, because it lowers the bar for who might attempt this kind of intrusion significantly.
Once an attacker installs one of these compromised shims, the signed firmware chain that Secure Boot is supposed to enforce becomes meaningless. From that point, malicious firmware can be loaded early in the boot sequence – before the operating system, before security software, before anything a user or IT administrator might be monitoring. The malware embeds itself at a level where standard defenses don’t reach.
What makes this particularly difficult to address after the fact: the infection survives a full OS reinstall. It also survives replacing the hard drive. Because the malicious firmware lives in the UEFI layer on the motherboard itself, wiping or swapping storage doesn’t remove it. For most users, and even many IT teams, that’s not a recovery scenario anyone is prepared to handle.
Both Windows and Linux users are exposed. The shim vulnerability doesn’t discriminate by operating system – these shims can be installed on devices running either platform, which means the affected population is effectively anyone using a machine with UEFI Secure Boot enabled and one of these unrevoked shims accessible.
The attack surface here isn’t obscure. These firmware images have been publicly available for over a decade. The oldest confirmed defective image dates to 2013, which means that for most of Secure Boot’s existence – from 2012, when it was introduced alongside Windows 8, through today – a simple bypass existed and was knowable to anyone who went looking.
Microsoft’s Role and What Remains Unresolved
The structural problem is straightforward: Microsoft invented Secure Boot, Microsoft runs the shim-signing program, and Microsoft is responsible for revoking compromised images once vulnerabilities are found. None of those revocations happened for these 11 images. Whether that’s the result of a process failure, inadequate tracking, or something else isn’t something ESET’s findings answer directly.
What the discovery does make clear is that a security feature’s value is only as durable as the organization maintaining it. Secure Boot has been treated by device manufacturers and operating system vendors as a reliable foundation – something you build on top of without questioning. The ESET research puts that assumption under pressure. If revocation isn’t happening, and defective signed images remain in circulation for 13 years, the question isn’t just what went wrong. It’s what else, right now, might be similarly unrevoked and waiting.
