A validly signed file just booted a system it should never have been allowed near. No forged certificate, no cracked private key, no memory corruption — the signature is real, issued years ago by Microsoft itself. That is the entire attack.
TL;DR
- ESET Research found 11 old UEFI shim bootloaders (version 0.9 or earlier) that are still validly signed by Microsoft’s third-party CA and bypass Secure Boot.
- Tracked as CVE-2026-8863 (the vulnerable shim collection) and CVE-2026-10797 (a signature-verification bypass caused by two functions reading a PE binary’s size field from different locations).
- Exploitation needs only access to the EFI System Partition and a copy of one of the 11 binaries — no exploit development, no reverse engineering.
- The June 2026 Patch Tuesday added dbx revocations for these 11 specific files. It does not fix the underlying trust model.
- An unknown number of pre-2017 signed shims almost certainly still exist and remain unrevoked, because no complete inventory of them exists.
Why This Matters
Secure Boot is the mechanism that is supposed to guarantee your computer only runs software signed by a trusted authority before the operating system even loads. It is the last line of defense against bootkits — malware that installs itself in the boot chain, before Windows, before your antivirus, before anything that could detect it, ever runs.
If Secure Boot can be bypassed with a file that was never revoked, that guarantee quietly stops meaning anything. This affects Windows and Linux systems alike, corporate laptops and servers, and it doesn’t matter whether the vulnerable software was ever installed on the machine — the attacker brings their own copy.
What Is a UEFI Shim, and Why Does One From 2015 Still Matter?
To understand the bug, you need to understand what a “shim” actually does.
UEFI Secure Boot works by only allowing signed code to run during startup. Microsoft controls the master keys most PCs ship with. Since Microsoft can’t personally review and sign every Linux distribution’s bootloader, it created a workaround: the shim.
A shim is a small, Microsoft-signed program whose only job is to then verify and load the next stage of the boot process — typically GRUB2 on Linux — using its own, separate trust list. Think of it as a bouncer who’s been vetted by the building owner (Microsoft), and who then checks IDs against his own guest list for who gets into the actual party (the OS bootloader).
The problem: shims are supposed to be updated when new vulnerabilities are found downstream, in GRUB2 or in the shim itself. ESET found 11 shims — some dating back to 2015, associated with Red Hat Enterprise Linux 7.2, Oracle Linux, PC-diagnostic tools, and other UEFI utilities — that were never updated and never revoked. Microsoft’s signature on them is still technically valid.
As ESET put it plainly in their research:
“What makes these old shims dangerous is not a novel vulnerability, it’s that no new vulnerability is needed to bypass UEFI Secure Boot.”
Three Ways an Old Shim Breaks the Chain
None of the three mechanisms below are new discoveries by themselves. What’s new is that ESET catalogued shims old enough to be missing all three protections simultaneously — and confirmed Microsoft’s signature still validates them.
1. Trusting an Already-Broken GRUB2
Some of the flagged shims embed vendor certificates that still trust GRUB2 binaries affected by CVE-2015-5281, a decade-old bug that “allows local users to bypass intended Secure Boot restrictions and execute non-verified code via crafted multiboot modules.”
In practice: the shim itself boots fine and passes its own signature check. It then hands control to a GRUB2 build that has its own, older hole — one that lets an attacker load an unsigned kernel through a crafted multiboot2 module. The shim never sees a problem, because it never re-checks what GRUB2 does after handoff.
2. Ignoring the Denylist (MOK)
Windows and Linux both maintain deny lists for compromised certificates — think of it as a blocklist. On the shim side, this is called MOK (Machine Owner Key), and the actual deny list is MokListX.
Support for reading MokListX was only added in shim version 0.9. Every version before that silently ignores it. So even if an administrator explicitly revoked a certificate through MOK, a pre-0.9 shim will happily trust it anyway — the deny list exists, but nothing is enforcing it.
3. Not Knowing About SBAT
SBAT (Secure Boot Advanced Targeting) is a newer, more granular revocation system introduced in shim version 15.3. It lets vendors revoke by generation and component, not just by individual certificate — closing gaps the older MOK system couldn’t reach.
Shims older than 15.3 have no idea SBAT metadata exists. They don’t read the .sbat section, don’t check SbatLevel, and therefore can’t be stopped by any revocation issued through this newer mechanism — even though that mechanism is what modern Linux distributions rely on today.
CVE-2026-10797: When the Signature Check Lies to Itself
The more surgical bug in the disclosure is CVE-2026-10797, a signature-verification bypass that affects shim 0.9 and below directly.
Authenticode-signed PE binaries store their size in two places. ESET found that the function shim uses to check for revocation and the function it uses to verify the signature each read that size value from a different one of those two locations.
| Function | Reads size from |
|---|---|
| Revocation check | Location A |
| Signature verification | Location B |
By carefully tampering with the WIN_CERTIFICATE structure, an attacker can construct a binary where the revocation check looks at a size value that makes it think “this isn’t the certificate I’m supposed to block,” while the signature verification — reading the other, untouched value — still validates the file as genuinely signed. The revocation logic and the trust logic are looking at two subtly different files without knowing it.
This bypass is narrower than the three mechanisms above — it only defeats revocations tied to embedded certificates — but it’s the clearest example of the disclosure’s overall theme: no single catastrophic flaw, just small inconsistencies that add up to a fully working bypass.
What an Attacker Actually Needs
This is the part that should concern defenders more than the technical mechanism itself. The attack requirements are almost boring:
- Physical or administrative access to the EFI System Partition (ESP)
- A copy of one of the 11 vulnerable shim binaries — all are publicly available, since they shipped in real, legitimate software
- No memory corruption, no ROP chains, no custom exploit development, no reverse engineering
Once a vulnerable shim is placed on the ESP and set as the boot target, an attacker can load unsigned code during boot — the exact precondition needed to deploy a UEFI bootkit such as Bootkitty, HybridPetya, or BlackLotus. We covered how that class of malware operates and why it’s so hard to detect in UEFI Bootkits: The Malware That Lives Below Your Operating System.
Crucially — and this is the detail that makes the scope so wide — exploitation is not limited to systems that ever had the vulnerable software installed. Any UEFI system that trusts Microsoft’s third-party CA is a valid target, regardless of its OS or installed applications, because the attacker supplies the malicious shim themselves.
Timeline: A Slow, Careful Disclosure
| Date | Event |
|---|---|
| Feb 16, 2026 | ESET reports findings to CERT/CC with proof-of-concept |
| Mar 18, 2026 | Public disclosure initially scheduled for May 19, 2026 |
| Mar 30, 2026 | Disclosure postponed to June 9, 2026 |
| Jun 9, 2026 | Microsoft’s Patch Tuesday ships dbx revocations; CERT/CC publishes its Vulnerability Note |
| Jul 14, 2026 | ESET publishes full research |
Researcher Martin Smolár of ESET Research led the discovery and coordinated disclosure over nearly five months — standard practice for a bug in a component this foundational, where a rushed disclosure could tip off attackers before defenders have a patch to deploy.
Patch Tuesday “Fixed” This — But Only the Part We Can See
Here’s the twist that makes this disclosure worth paying attention to, not just filing away as “patched.”
Microsoft’s June 2026 Patch Tuesday added the 11 known-vulnerable binaries’ hashes to dbx, the UEFI Secure Boot Forbidden Signature Database. In effect: eleven specific doors got bricked shut.
That is not the same as fixing the lock.
Dbx revocation blocks known, identified binaries by hash. It does nothing about the structural reality ESET is pointing at: Secure Boot’s shim ecosystem trusts any old Microsoft-signed shim by default, and no complete inventory of those shims exists. The current tracking system — the shim-review GitHub repository — only started in 2017. Anything signed before that has no guaranteed public record. Nobody can revoke what nobody has catalogued.
That means this is, functionally, a game of whack-a-mole: researchers (or attackers) find an old signed shim, it gets added to dbx, and the underlying trust model — “if Microsoft signed it, boot it” — remains exactly as permissive as it was before. The 11 revoked hashes are the ones we know about. The realistic assumption for defenders should be that they are not the only ones that exist.
What You Can Do Today
On Windows:
- Confirm the June 2026 cumulative update (or later) is installed — that’s what ships the dbx revocations.
- Use PowerShell to check your system’s current dbx contents against the 11 published hashes to confirm the revocation actually landed on your hardware. Firmware updates on some OEM devices lag behind Windows Update for dbx changes — verify, don’t assume.
On Linux:
- Check for updates through the Linux Vendor Firmware Service (LVFS).
- Run the
uefi-dbx-auditscript to confirm your system’s revocation list is current.
For both:
- Treat the EFI System Partition as a security boundary, not just a technical one. Anyone who can write to it can potentially stage one of these binaries.
- If you manage fleets of devices, especially air-gapped or infrequently-updated hardware, dbx propagation is not guaranteed by default — build a verification step into your patch management process rather than trusting that “Windows Update ran” means the firmware-level revocation applied.
- Don’t treat this as closed. Monitor CERT/CC and ESET’s advisories for additional revoked hashes as more legacy shims are identified.
Related Posts
- UEFI Bootkits: The Malware That Lives Below Your Operating System — what happens once an attacker actually gets unsigned code running at boot time, and why it’s nearly invisible to your OS-level defenses.
- YellowKey: The BitLocker Bypass Hidden in Windows Recovery — another case where a trusted, signed pre-OS component turned out to be the weak link.
- GreatXML: When a Setup File Unlocks BitLocker — the broader pattern of recovery/pre-boot environments being treated as security boundaries when they weren’t designed to be.