Old Microsoft-Signed UEFI Shims Continue to Enable Secure Boot Bypass — Coordinated Vendor Response

The eleven old Microsoft-signed UEFI shims that could bypass Secure Boot have now been revoked — and for defenders, the work shifts from disclosure to getting the revocation deployed.

REDMOND, WASH. — Fresh coverage published on July 15-16, 2026 has filled in the coordinated vendor response behind the eleven old Microsoft-signed UEFI shims that could reportedly be used to bypass Secure Boot, the firmware-level trust check meant to ensure only signed, trusted code runs before an operating system loads. Where the initial disclosure the prior week framed the finding as an open question about the durability of Secure Boot trust, this week's reporting supplies the resolution: the shims have been revoked. The defender story accordingly moves from what was found to what has been done about it, and to the deployment work that revocation still requires across real fleets.

The reporting rests on research from ESET. As SecurityWeek summarized it under the headline "Old UEFI Shims Expose Systems to Secure Boot Bypass," the vulnerable, Microsoft-signed UEFI shims could be abused on any system regardless of the OS. Dark Reading, writing under "Forgotten Bootloaders Expose Secure Boot Blind Spot," documents that the shims have now been revoked. Together the two accounts turn a research disclosure into a patch-management story, and that reframing is what shapes the defender to-do list this week.

What SecurityWeek and Dark Reading Documented

The through-line across both accounts is that the eleven old UEFI shims are dangerous not because of a novel flaw but because they remained trusted long after they should have been retired. As Dark Reading reported, the shims ESET identified were version 0.9 or earlier — many generations behind current releases — and either launched vulnerable second-stage bootloaders, lacked newer protections, or carried flaws that could be used to bypass Secure Boot. They nonetheless stayed valid, Microsoft-signed components in the Secure Boot chain, which is the property that made them a broad concern rather than a distribution-specific bug.

The reach comes from the signature, not the software. Per SecurityWeek, ESET's assessment is that the shims could be used to bypass Secure Boot on any UEFI-based machine that trusts the Microsoft Corporation UEFI CA 2011 third-party certificate authority, regardless of the installed operating system. Because a UEFI shim exists precisely to let a signed Linux distribution boot on hardware that trusts Microsoft's keys, a machine does not have to run any particular distribution to be exposed — if its firmware still trusts one of these old signatures, that trust travels wherever the signature is honored. Both outlets note the population of forgotten shims is hard to bound: shims approved before a 2017 documentation change were not fully recorded, so others may remain trusted.

Continuation Context: A Decade-Old Weakness and Eleven Shims

This week's reporting is the third beat in a connected sequence. It follows a separately reported decade-old Secure Boot weakness, which examined how long a single flaw can persist in the boot path, and the disclosure of eleven old Microsoft-signed UEFI shims that could bypass Secure Boot. The earlier shim coverage stressed an open scope question — how many still-trusted shims are out there — and framed revocation as the likely eventual fix. The new reporting closes part of that loop by confirming the coordinated response, while leaving the deployment and completeness questions open.

The common thread across all three is that Secure Boot's guarantees depend on the ongoing trustworthiness of code signed years ago, and that revoking that trust after the fact is slow. It is the same tension organizations are already weighing ahead of an industry-wide Secure Boot signing-key deadline affecting Windows and Linux, and it rhymes with adjacent low-level research such as the Apple A12/A13 bootROM work. The recurring defender lesson is that boot-time trust is not set-and-forget; it has to be maintained through revocation and updates.

The Coordinated Revocation Response

The response was coordinated through the standard disclosure channels rather than dropped cold. According to SecurityWeek, ESET reported its findings to CERT/CC in February 2026, and Microsoft subsequently revoked the vulnerable shims through Secure Boot deny-list updates, adding them to the UEFI forbidden-signature database. That is the cleanest structural fix available, because deny-listing a signature removes the trust that makes an old shim useful in the first place, rather than requiring every downstream system to be patched individually.

The sequencing matters, and CERT/CC has been specific about it. As SecurityWeek relayed, administrators should update the signature database of trusted boot applications and certificates first, and only then deploy the revocation list; doing it in the wrong order risks systems rejecting newly updated, legitimate boot components. CERT/CC further advised that enterprises, virtualization providers, and cloud operators managing large-scale deployments prioritize validation and rollout so that vulnerable or unsigned binaries are not executed during physical or virtual machine startup. The revocation, in other words, is real, but it only protects systems that have received and correctly applied it.

That caveat is the crux of the defender story. Revocation shipped, but it is not self-enforcing: a machine that has not taken the deny-list update still trusts the old shims. Sources cited in this week's coverage caution that firmware-layer patching typically lags application patching by a wide margin, especially where legacy hardware, air-gapped systems, or change-control cycles measured in quarters are involved, so meaningful exposure windows can stretch for months. The revocation is best read as the start of a rollout, not the end of the problem.

Defender Posture for Secure Boot Deployments

For teams running Secure Boot deployments, the practical work is now deployment tracking rather than triage of an unknown. The first step is inventory: knowing which shim and boot-loader versions are actually present across servers, workstations, and virtual machines, and which predate current maintained releases. Old, unattended systems imaged years ago and never re-provisioned are exactly where forgotten Microsoft-signed shims are most likely to linger, so an accurate boot-component inventory is the prerequisite for confirming that revocation has taken hold.

From there, the levers are ordinary firmware-trust hygiene applied in the right order. Following the guidance in this week's reporting, that means updating the trusted-boot signature database before applying the revocation list, so a machine does not reject legitimate updated components. Keeping shim and boot-loader packages current through normal distribution channels ensures systems run maintained versions rather than the revoked binaries. And because Secure Boot is a boot-time control that sits below the operating system, monitoring for boot-integrity changes gives security operations a chance to notice tampering that endpoint tooling running inside the OS would miss.

This work also folds neatly into patch programs already in motion. The revocation reached systems through Microsoft's monthly update cadence, the same channel tracked in the June 2026 Patch Tuesday release, so a shim-and-revocation audit belongs inside the existing patch-management workstream rather than as a separate fire drill. The objective is consistent: ensure the only signed boot code a machine trusts is code that is still meant to be trusted, and confirm that the deny-list update has actually landed rather than assuming it.

Open Questions

Even with the revocation confirmed, material questions remain. The timeline for widespread revocation deployment is not established: sources in this week's coverage expect firmware-layer rollout to trail ordinary patching, but there is no published schedule for when the bulk of affected fleets will have applied the deny-list update. Organizations should therefore treat their own deployment status as something to verify directly rather than assume.

It is also not confirmed whether every Linux distribution can accept the revocation cleanly. Deny-listing a signature that still appears in legitimate boot media risks breaking recovery images, rescue disks, and older-but-valid installations that rely on the same signed component, which is precisely why platform maintainers stage revocation carefully. How that plays out across the full range of distributions and hardware has not been detailed, so testing revocation against recovery media before wide deployment remains the prudent stance.

Finally, the completeness of the fix is bounded by history. Because shims approved before the 2017 documentation change were not fully recorded, this week's coverage is careful to note that other old, still-trusted shims may remain beyond the eleven that were revoked. None of that undercuts the confirmed core — that the eleven old Microsoft-signed UEFI shims which could bypass Secure Boot have now been revoked — but it does mean defenders should treat revocation as an ongoing discipline rather than a one-time event.

The CyberSignal Analysis

The reported facts above come from ESET's research and the coverage by SecurityWeek and Dark Reading; what follows is The CyberSignal's editorial reading of what defenders should take from them. None of the judgments below are new reported facts.

Signal 01 — The Fix Shipped, but Deployment Is the Real Metric

The most important shift in this week's news is that the story is no longer about discovery; it is about distribution. Revocation has been issued, which means the open question is no longer whether a structural fix exists but whether it has reached each machine. Our reading is that defenders should measure their exposure by deployment status — has this system taken the deny-list update, in the correct order — rather than by whether a patch has been published somewhere upstream.

That distinction changes what good looks like. An organization that treats the announcement as closure will carry silent exposure on every machine that has not applied the revocation; one that treats it as the start of a rollout will instrument for confirmation. The teams that come through this well will be the ones that can answer, per host, whether the revoked shims are still trusted, not the ones that assume a vendor action automatically protects them.

Signal 02 — The Trust Anchor, Not the Shim, Is Still the Target

Even with eleven specific shims named and revoked, the durable lesson is that the risk lived in a shared trust anchor — a Microsoft-signed certificate honored across otherwise unrelated systems — not in any single binary. Our assessment is that defenders should keep modeling this as a property of the signature ecosystem, because that is how the exposure propagated in the first place and how any future forgotten shim would too.

Practically, that argues for framing the response as 'which of my machines trust boot code they no longer should,' and for keeping the revocation database current as the primary control. Chasing individual binaries host by host is the harder, less complete path; maintaining trust hygiene at the deny-list layer is what actually retires the risk across a fleet.

Signal 03 — Firmware Revocation Is a Discipline, Not an Event

This episode rhymes with a run of low-level findings in which trust granted at the boot layer is rarely revisited until research forces the issue. Our view is that the recurring theme — visible here, in the decade-old Secure Boot weakness, and in adjacent bootloader research — is that revocation discipline, executed without breaking legitimate boot media, is what keeps a boot-trust chain honest over time.

The forward-looking watch item is completeness and cadence: whether the ecosystem can enumerate and retire the remaining undocumented pre-2017 shims, and how quickly firmware-layer revocation actually propagates to legacy and air-gapped systems. We would judge the ultimate handling of this less by the speed of the initial announcement and more by whether organizations build the standing capability to inventory boot trust and confirm revocation — the difference between a control that works on paper and one that works in the field.

Sources