For 13 of its 14 years, Secure Boot could be bypassed
For 13 of its 14 years of existence, an industry-wide standard Microsoft invented to protect Windows—and later Linux—devices from firmware infections has been trivial to bypass, researchers at ESET found. The discovery centers on signed firmware images known as "shims" that, despite being known to be defective, remained publicly available and signed by Microsoft.
ESET researchers identified 11 defective shim images, at least one from 2013
ESET’s analysis turned up 11 firmware images that were "known to be defective" yet continued to bear Microsoft’s signature. At least one of those images dates to 2013. The presence of those signed, defective images in the public ecosystem is the concrete trigger for the vulnerability ESET described: because the images remained signed, they could be used to bypass the protections Secure Boot is intended to provide.
What shims are and why they matter to Secure Boot and UEFI
Shims were invented to extend Secure Boot to Linux devices and utility software. Secure Boot is embedded into the UEFI (Unified Extensible Firmware Interface) of a device’s motherboard; it is supposed to prevent firmware infections by ensuring only trusted, signed code runs early in the boot process. Shims act as intermediary, signed binaries that allow other software—typically non‑Windows bootloaders and utilities—to operate under Secure Boot’s checks.
How old, signed shims became a trivial bypass
According to the details reported by ESET, the problem is not a new attack technique but an operational failure: old, "forgotten" shim images that contained defects were not revoked after those defects were discovered. Because the images remained signed and publicly available, attackers can use them to completely circumvent Secure Boot. The technique is described as simple enough to be performed by novice hackers, turning a decades‑old protection mechanism into an ineffective barrier whenever those shims are present.
Microsoft’s role: signing and failure to revoke
The situation stems from Microsoft’s role in overseeing the signing of shims. The reporting attributes the "gaffe" to Microsoft’s failure to revoke the defective, publicly available images once vulnerabilities were found in them. That lapse left signed binaries in circulation that undermine the guarantee Secure Boot is intended to provide: that only trusted, signed firmware and boot software will run.
What this means for technologists, affected enterprises, and end users
- Technologists and security teams: Will watch for the presence of legacy, signed shim images in firmware inventories and worry that signed-but-defective images can nullify UEFI protections. They will also need to reassess trust assumptions about signature provenance if signatures that should have been revoked remain usable.
- Affected enterprises and procurement leaders: Will be concerned that devices purchased or deployed over the last decade may contain publicly available, signed shim images dating back to at least 2013, creating an unexpected attack surface in managed fleets where firmware integrity was assumed.
- End users: Should note that the protection embedded in their device motherboards (UEFI Secure Boot) can be rendered ineffective by old, signed shims that remain available—meaning firmware‑level compromise is possible even when a device appears to enforce Secure Boot.
This episode is a narrow technical story with broad consequences: a mechanism designed to constrain firmware‑level compromise was undercut not by an exotic new exploit but by signed binaries that should have been retired. The record presented by ESET points to a single operational failure—signed, defective shims that were not revoked—that had system‑wide implications for a firmware protection standard spanning more than a decade. The unanswered practical question left by the facts as reported is simple and consequential: will the signed, defective images be revoked or otherwise neutralized to restore the integrity of Secure Boot?
