Introduction
ESET recently published a new article reporting 11 old shim bootloaders signed with the Microsoft Corporation UEFI CA 2011 certificate.
It is worth setting out why that certificate carries so much weight. shim is the small loader that lets Linux boot on Secure Boot hardware: distributions cannot get their own keys into every vendor's firmware, so they ship a Microsoft-signed shim instead, and that shim vouches for whatever runs next. Microsoft Corporation UEFI CA 2011 is the third-party CA behind that arrangement, and it sits in the db of practically every x86 machine shipped in the past decade. Anything it signed is trusted almost everywhere, by default.
This is what makes the attack surface interesting. Microsoft has revoked those 11 shims, but the non-revoked shims shipped by other Linux distributions remain unaccounted for. In other words, beyond those 11, an attacker can still bypass Secure Boot with any non-revoked shim signed by the same certificate. These binaries are not difficult to obtain either; they sit in distribution archives, on old installation media, and inside vendor recovery images, and nothing prevents anyone from pulling a decade-old bootloader out of a mirror that is still online.
The certificate itself expired on June 27th, 2026 and this is exactly where the danger shows itself: expiration has no effect on how Secure Boot behaves. If a shim bootloader is signed with Microsoft Corporation UEFI CA 2011 and has not been added to the dbx list, Secure Boot will still verify it, and without SBAT, nothing further stops it from running.
The rest of this post covers the mechanisms meant to prevent exactly that — SBAT and MOK — where the verification chain actually breaks, how to tell a vulnerable shim from a patched one, and a working demonstration of the bypass.
SBAT
SBAT (Secure Boot Advanced Targeting) is a revocation mechanism designed to solve a structural problem the classic Secure Boot databases could not scale to. Traditionally, an untrusted binary is blocked by adding its Authenticode hash or signing certificate to dbx, the UEFI Forbidden Signature Database. But dbx is allotted only 32 KB of space, and the number of Linux components executed during boot makes listing each of them individually impractical.
SBAT reframes the problem: where dbx revokes binaries, it revokes versions. The mechanism works by embedding generation numbers into the EFI binaries themselves, and it was introduced in shim 15.4.
MOK
dbx and SBAT both revoke centrally — the decision is made by the firmware vendor or by Microsoft and pushed down to every machine. MOK (Machine Owner Key) hands revocation and trust authority to the person who actually owns the hardware. This is the layer that lets a Linux user act on their own, without waiting for a firmware dbx update or an upstream SBAT bump.
The problem MOK solves is one of authority, not scale. UEFI's db and dbx are managed under the Platform Key and the Key Exchange Key — trust roots the end user does not control on a locked-down, Microsoft-signed system. Enrolling your own signing certificate, or revoking one you no longer trust, would normally mean touching firmware-owned databases you hold no key for. shim breaks this deadlock by carrying its own verification layer and its own set of NV EFI variables, enrolled through MokManager (mm*.efi) with password confirmation standing in for physical presence.
Chain of SBAT + MOK
On Linux, Secure Boot is not a single check; it is a relay. Each stage verifies the next before handing over execution, and the guarantee only holds if every link enforces the same policy. SBAT and MOK are the two mechanisms that turn that relay's static "is this signed?" check into a revocable one:
The verification chain traces four hops, each validating the one after it:
UEFI Firmware — Holds db (allowed signatures) and dbx (forbidden signatures), anchored by Microsoft's UEFI CA 2011 certificate. This is the trust every stage above it inherits.
shim — A small, Microsoft-signed first-stage loader. The firmware validates shim's Authenticode signature against db. shim then carries its own three trust anchors: the built-in shim/vendor certificate, the MS db certificate, and the machine-owner list (MokList).
Second-stage bootloader (GRUB2) — Verified against shim's anchors, not the firmware's. This is the hand-off point where distro-specific and owner-specific trust takes over.
Linux kernel — GRUB, through shim's protocol, verifies the kernel image against the same vendor certificate before boot completes.
The decision node is where the chain compresses its real logic. That single Trusted? gate is actually three independent questions stacked on top of each other, and SBAT and MOK are two of them.
Investigating the Shims
I investigated several shims and collected the research in the CVE-2026-8863 GitHub repo.
A forgotten shim looks like this (the BOOTX64.EFI file from CentOS 7.2):
# sha256sum: 1e6d991a38fe71485597585f2a1f6424bae20a8610c23668398cacc72602fd90
bekoo$CachyOS: > sbverify --list BOOTX64.EFI
warning: data remaining[1175992 vs 1296176]: gaps between PE/COFF sections?
signature 1
image signature issuers:
- /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
- subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
If the file carries no .sbat section, the shim will still execute (SBAT was introduced in shim 15.4). The shim version can be printed as well:
bekoo$CachyOS > strings -a BOOTX64.EFI | grep -Ei 'UEFI SHIM|\$Version:|\$Commit:'
UEFI SHIM
$Version: 0.9 $
$Commit: 21b10566b2c88b3ae0d8dcb99fe95264832c6f6a $
CVE-2026-8863 covers the old shim versions — 0.9 and anything below 15.4.
When you investigate a shim bootloader, check both the certificate and the shim version. A shim reporting version 0.9 is vulnerable and will not contain a .sbat section.
On Red Hat–based distributions such as CentOS or Scientific Linux, known GRUB CVEs can be executed on the system as well. These GRUB binaries also carry a certificate, but since the Secure Boot chain is already broken at the shim stage, that verification can be bypassed just as safely:
# sha256sum: 3f2196d8330ef5225f254478067a5c3bb293502149b535b30a6f25cfda2a0bb1
bekoo$CachyOS > sbverify --list grubx64.efi 00:12
signature 1
image signature issuers:
- /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert EV Code Signing CA (SHA2)
image signature certificates:
- subject: /businessCategory=Private Organization/jurisdictionC=US/jurisdictionST=Delaware/serialNumber=2945436/street=100 East Davie Street/postalCode=27601/C=US
issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert EV Code Signing CA (SHA2)
- subject: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert EV Code Signing CA (SHA2)
issuer: /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
And that is what makes the attack dangerous.
Bypassing Secure Boot
Here is a video on Vimeo:
I used CVE-2026-8863 together with CVE-2015-5281 in the video (the same combination used in ESET's PoC).
As the video shows, the exploit is straightforward. I simply copied the files into place -BOOTx64.EFI (the old shim signed with the certificate) and grubx64.efi - and restarted the system. grub.cfg contains a single directive, multiboot2, which is what loads my own kernel.elf file.
Top comments (0)