Unrevoked Shims Kept Secure Boot Broken for Years

Secure Boot was sold as a hard stop against bootkits. For most of its life it was not. Researchers at ESET showed that 11 Microsoft-signed UEFI shim images, some dating to 2013, remained trusted long after they were known to be defective. No clever exploit was required. An attacker only needed a copy of an old, still-signed shim and a basic grasp of how the secondary trust chain works. That was enough to load arbitrary early-boot code on both Windows and Linux machines.

Microsoft finally revoked the images in its June patch cycle after ESET and CERT raised the issue. The gap had lasted roughly 13 of Secure Boot’s 14 years. That is not a one-off signing mistake. It is a structural failure in how firmware trust is maintained, and it lands squarely on systems engineers who treat Secure Boot as a solved checkbox.

The shim is a second root of trust

On a Windows machine, the digitally signed Windows Boot Manager is the primary anchor. Everything that runs next must chain to a certificate Microsoft put in the allowed signature database (db) and must not appear in the forbidden database (dbx).

Linux distributions and third-party utilities cannot live entirely inside that model. The dbx is tiny (about 32 KB). Listing every legitimate boot component by hash is impractical. So the industry invented the shim: a small Microsoft-signed first-stage loader that embeds its own certificate and then authorizes a second-stage bootloader (GRUB, a recovery tool, a diagnostic image). The shim becomes a secondary root of trust. Whoever controls the certificate baked into that shim effectively controls what runs before the OS.

The 11 forgotten shims were built for Red Hat, openSUSE, Oracle, PC-Doctor, and even Finland’s Matriculation Examination Board software. Many predated later defenses such as SBAT (Secure Boot Advanced Targeting) and MOK deny lists. Some carried known bugs in the shim itself or in the second-stage binaries they would happily load. Because Microsoft never pushed their hashes or certificates into dbx (or equivalent version-based policy), they stayed valid boot anchors.

Martin Smolár of ESET put it cleanly: the danger is not a novel vulnerability. “An attacker needs no complicated exploitation primitives—only a copy of an old, still-trusted, but unrevoked shim binary.” Physical access is still the classic threat model Secure Boot claims to cover. With an unrevoked shim, that access is enough to install persistent firmware-level malware that survives OS reinstall and disk replacement. Bootkits such as LoJax, MosaicRegressor, CosmicStrand, and BlackLotus already demonstrated why that early foothold matters.

Revocation is harder than signing

Microsoft’s process looks sound on paper. When a component is compromised, it is supposed to be revoked via dbx, or via version-based mechanisms when hash lists would overflow the firmware variable. SBAT and Secure Boot Security Version Numbers (SVN) exist precisely because listing every broken binary is impossible. Each component carries signed metadata with a generation number. The shim enforces a minimum generation; outdated builds reject themselves and anything they would load.

That machinery only works if someone actually updates the policy and ships it. The 11 shims sat outside effective revocation for years. Microsoft has not explained the miss. Complexity is the obvious suspect. Two databases, multiple certificates, OEM-controlled Platform Keys and Key Exchange Keys, Windows Update paths that sometimes require a prior firmware update, and a separate policy channel for SBAT all have to stay in sync. One stale signed binary is enough to punch a hole through the whole chain.

The same brittleness shows up in the broader certificate migration from the original 2011 Secure Boot CA toward the 2023 certificates. Some devices cannot apply the new trust anchors until the OEM ships a firmware update. Microsoft has paused automatic certificate issuance for affected machines (including certain HP models) while partners work on fixes. Until then, machines keep booting, but they stop receiving new early-boot protections. Over time they become progressively less protected. Secure Boot is “on” in the UI while the trust root quietly ages out.

What systems engineers should actually do

If you manage fleets, dual-boot developer laptops, or CI hardware that boots from USB recovery media, treat this as an inventory and configuration problem, not a waiting-for-Microsoft problem.

Inventory the boot chain. On Windows, confirm Secure Boot is enabled and that certificate servicing is progressing. Microsoft documents the Secure-Boot-Update scheduled task and the AvailableUpdates registry bitmask used to stage certificate work. If the task is missing, disabled, or stuck, certificate and DBX updates will not land. On Linux, check that the installed shim is recent enough to carry current SBAT policy and that mokutil --list-enrolled / deny-list state matches what you expect.

Prefer version-based revocation over hope. SBAT only helps if every machine has a shim new enough to enforce it and if the policy variable (SbatLevel) has been updated. Old recovery USBs and golden images are a common source of unrevoked shims. Rebuild them. Do not keep a 2015 “works everywhere” installer stick in the drawer.

Assume OEM lag. Certificate and DBX updates often require a firmware step first. Track vendor Secure Boot support pages for the models you own. A Windows Update that claims success while the firmware still only trusts 2011-era material is a false green light. Microsoft’s own troubleshooting guidance is explicit: some platforms need an OEM firmware update before automated certificate servicing can finish.

Threat-model physical and supply-chain access. Secure Boot is not magic against a sophisticated implant if the attacker can present a still-trusted first-stage loader. For high-value build machines and admin workstations, combine Secure Boot with measured boot / TPM attestation, full-disk encryption that binds to PCR state, and physical controls. Turning Secure Boot off to “just get the machine to boot” after a botched update is a common recovery path; document how to re-enable it with factory keys rather than leaving it disabled.

Dual-boot and custom loaders need extra scrutiny. Any workflow that installs a third-party bootloader, a custom recovery environment, or a Linux distribution that still ships an older shim is reintroducing the exact class of binary that sat unrevoked for a decade. Prefer distributions that ship current shim + SBAT and that document their revocation story.

The pattern, not the incident

The shim story and the certificate-update failures are the same class of failure: a distributed trust system where signing is centralized and easy, revocation is distributed and hard, and enforcement depends on firmware that OEMs update on their own schedule. Microsoft sits at the center because Windows machines treat its UEFI certificates as the universal gate. That design made Linux and utility boot possible under Secure Boot. It also made Microsoft’s revocation hygiene the single point of failure for everyone else.

Bootkits that survive disk replacement are still rare compared with userland malware. They remain high-impact when they appear, which is exactly why Secure Boot exists. A protection that is trivial to bypass with a ten-year-old signed binary is not protecting against its stated threat model. The June revocations close this particular set of shims. They do not fix the operational reality that another forgotten, still-signed first stage can sit in the wild until someone bothers to look.

For working systems engineers the takeaway is unglamorous. Maintain an inventory of what actually boots your machines. Keep recovery media and golden images on a short leash. Verify that SBAT and certificate updates have landed rather than assuming the Secure Boot LED means the chain is current. Trust is not a setting. It is a living list of what you still allow to run before the kernel, and that list is only as strong as the last revocation you successfully shipped.