# 11-Year-Old Linux UEFI Shim Bootloader Flaws Enable Secure Boot Bypass (CVE-2026-8863, CVE-2026-10797)

> ESET Research identified 11 obsolete, still Microsoft-signed UEFI shim bootloaders (v0.9 and earlier) shipped by Red Hat, Oracle, openSUSE, Spyrus, Baramundi, WhiteCanyon/Blancco, Finland's Matriculation Examination Board, NTC IT ROSA, and PC-Doctor that let an attacker bypass UEFI Secure Boot and execute untrusted code during system boot. CVE-2026-10797 is a signature-length confusion between the PE header and WIN_CERTIFICATE structure that lets a certificate revoked in dbx/MokListX slip past the shim's revocation check; CVE-2026-8863 covers the related shim-side bypass paired with old, unrestricted GRUB 2 (CVE-2015-5281) multiboot2 loading to achieve arbitrary unsigned code execution. Microsoft revoked all 11 vulnerable shim hashes via a dbx update on the June 9, 2026 Patch Tuesday after ESET's February 2026 disclosure to CERT/CC.

- **Published:** 2026-07-14T00:00:00Z
- **Last reviewed:** 2026-07-14T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1340
- **ID:** TL-2026-1340
- **Severity:** HIGH (CVSS 7.8)
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 19 (full data via the Threadlinqs MCP server — Purple tier)
- **CVEs:** CVE-2026-8863, CVE-2026-10797, CVE-2015-5281

## Description

In February 2026, ESET researcher Martin Smolar reported to CERT/CC that 11 old UEFI shim bootloader binaries, all signed by the third-party 'Microsoft Corporation UEFI CA 2011' certificate authority and all at shim version 0.9 or earlier, remained fully trusted by any UEFI-based Secure Boot chain despite carrying long-known, already-patched-upstream vulnerabilities. The root cause is that downstream vendors forked shim years ago and never rebased onto fixed upstream releases, so their forked binaries kept shipping (and remaining trusted) with the flaws intact.

The technical crux, tracked as CVE-2026-10797, is a discrepancy in how an Authenticode-signed PE binary records its own signature length: once in the PE header's IMAGE_DIRECTORY_ENTRY_SECURITY data directory, and again inside the embedded WIN_CERTIFICATE structure. In the affected shim builds, the function that performs dbx/MokListX certificate-based revocation checks trusts the WIN_CERTIFICATE-embedded length, while the function that performs Authenticode signature verification trusts the PE header length. An attacker who tampers with the WIN_CERTIFICATE structure of a second-stage bootloader (e.g., GRUB 2) can steer the revocation-check routine toward the wrong byte range, so a certificate that has actually been revoked in dbx or MokListX is never recognized as revoked, while the separate signature-verification routine still validates the binary successfully using the correct, untampered bytes. This only works against certificate-based revocations (hash-based dbx entries are unaffected) and requires the second-stage loader to be signed by a certificate embedded in the shim's own trust chain.

CVE-2026-8863 covers the composite exploit chain: an attacker places one of the 11 legacimate, Microsoft-signed-but-vulnerable shim binaries plus an old, unpatched GRUB 2 build (itself carrying the decade-old CVE-2015-5281, which allows unsigned multiboot/multiboot2 kernel modules to be loaded without a signature check) onto a system's EFI System Partition. Firmware trusts and loads the old shim (it is still signed by a certificate in the system's `db`); the shim in turn validates GRUB 2 using its embedded vendor certificate; the revocation-check confusion above lets a revoked/malicious GRUB 2 pass; GRUB 2's multiboot2 loader then loads unsigned code with no further verification. The net effect is arbitrary code execution during the boot process on essentially any UEFI-based machine that trusts the Microsoft third-party CA, independent of which operating system (if any) is actually installed — this is functionally a 'Bring Your Own Vulnerable Driver' (BYOVD)-style attack applied to the boot chain rather than to a kernel driver.

Because execution happens before the OS kernel and any endpoint security agent initializes, a successful exploit can install a UEFI bootkit that persists across OS reinstalls and evades EDR/AV entirely — the same class of impact demonstrated by real-world bootkits Bootkitty (first UEFI bootkit targeting Linux), HybridPetya, and BlackLotus, all of which ESET cites as precedent. ESET deliberately withheld indicators of compromise, noting the vulnerable shims are embedded inside legitimate, widely distributed software packages (PC diagnostic tools, disk-wipe utilities, exam kiosk software, Linux installers) across an unknown number of systems, and publishing IOCs risked mass false-positive identification of benign, unexploited installations.

CERT/CC's VU#616257 enumerates confirmed-affected vendors: Spyrus WTGCreator (shim ≤0.7), Red Hat Enterprise Linux 7.2 and CentOS 7.2 (shim 0.9), Baramundi Management Suite up to 2024R1 (shim 0.8), WhiteCanyon/Blancco WipeDrive 8.0.0-8.1.3 (shim 0.7), Finland's Matriculation Examination Board's Abitti 1.0 exam software (shim 0.8), NTC IT ROSA Linux R9/R10 (shim 0.9), Oracle Linux 7.2 (shim 0.9), PC-Doctor Service Center 15/16 (shim 0.9), and openSUSE's UEFI shim loader 0.9/2.1. Intel and AMI confirmed their products do not contain the vulnerable shims; over 30 other vendors, including Dell, HP, Microsoft, and Lenovo, have an unknown/unconfirmed status as of publication. Disclosure was coordinated: an initial May 19, 2026 public-disclosure date was postponed to June 9, 2026 to align with Microsoft's Patch Tuesday dbx rollout. ESET published its full research write-up on July 14, 2026, noting that the Microsoft Corporation UEFI CA 2011 certificate's own June 27, 2026 expiration has no bearing on Secure Boot enforcement absent explicit hash-based dbx revocation of each individual vulnerable binary.

## MITRE ATT&CK

- T1592 Gather Victim Host Information
- T1588.003 Code Signing Certificates
- T1195 Supply Chain Compromise
- T1542.001 System Firmware
- T1542.001 System Firmware
- T1542.003 Bootkit
- T1547 Boot or Logon Autostart Execution
- T1553.002 Code Signing
- T1542.001 System Firmware
- T1211 Exploitation for Stealth
- T1685 Disable or Modify Tools
- T1014 Rootkit
- T1082 System Information Discovery
- T1495 Firmware Corruption
- T1195.002 Compromise Software Supply Chain
- T1553.006 Code Signing Policy Modification
- T1601.001 Patch System Image

## Sources

- [Forgotten UEFI shims undermining Secure Boot](https://www.welivesecurity.com/en/eset-research/forgotten-uefi-shims-undermining-secure-boot/)
- [VU#616257 - Microsoft-signed UEFI shim bootloaders vulnerable to Secure Boot bypass](https://kb.cert.org/vuls/id/616257)
- [11 Old Microsoft-Signed Linux UEFI Shims Could Let Attackers Bypass Secure Boot](https://thehackernews.com/2026/07/11-old-microsoft-signed-linux-uefi.html)
- [11-Year-Old Linux UEFI Shim Bootloaders Let Attackers Bypass Secure Boot](https://cybersecuritynews.com/11-year-old-linux-uef-bootloaders/)
- [No one knows how many old shims can still bypass UEFI Secure Boot](https://www.helpnetsecurity.com/2026/07/14/eset-uefi-secure-boot-bypass/)
- [Microsoft-signed UEFI bootloaders vulnerable to Secure Boot bypass](https://cyberinsider.com/microsoft-signed-uefi-bootloaders-vulnerable-to-secure-boot-bypass/)
- [CVE-2026-8863 Secure Boot Bypass: What It Means for Windows Boot Trust](https://windowsforum.com/threads/cve-2026-8863-secure-boot-bypass-what-it-means-for-windows-boot-trust.424383/)
- [CVE-2026-8863 Record](https://www.cve.org/CVERecord?id=CVE-2026-8863)
- [CVE-2026-10797 Record](https://www.cve.org/CVERecord?id=CVE-2026-10797)
- [microsoft/secureboot_objects (DBX update files)](https://github.com/microsoft/secureboot_objects)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1340