CVE-2026-8863, CVE-2026-10797 — forgotten pre-0.9 UEFI shims bypass Secure Boot via a signature-length validation mismatch
ESET Research published (2026-07-14) a full dissection of 11 Microsoft-signed UEFI shim bootloaders — all at shim version 0.9 or below — that undermine Secure Boot on any machine trusting the "Microsoft Corporation UEFI CA 2011" third-party certificate, independent of which OS is installed (ESET Research, 2026-07-14). The primary flaw (CVE-2026-10797) is a signature-length validation mismatch: an Authenticode-signed PE records its signature length in two places, and "the revocation check used the value from the signature header, while the signature verification function used the value from the PE header" (ESET Research, 2026-07-14), so an attacker can tamper the WIN_CERTIFICATE structure to make the revocation routine compare the deny-lists against bogus data while verification still succeeds. Two companion weaknesses in the same forgotten binaries (tracked with CVE-2026-8863) compound it: shims below 0.9 never enforce the MOK deny-list (MokListX), so an older still-trusted shim can be substituted to load a binary that was explicitly revoked, and shims before version 15.3 predate SBAT (Secure Boot Advanced Targeting) entirely, reopening old GRUB 2 bugs such as CVE-2015-5281 that SBAT was built to close.
Crucially, exploitation requires no complex exploitation primitive — "only a copy of an old, still-trusted, but unrevoked shim binary" copied to the EFI System Partition alongside a compatible second-stage bootloader (ESET Research, 2026-07-14); writing to the ESP is itself a privileged local operation (consistent with this entry's local, post-auth vector), so the technique is a persistence/defense-evasion primitive for an attacker who already has that access rather than a remote initial-access exploit. CERT/CC frames it as a "Bring Your Own Vulnerable Driver (BYOVD)-style technique to execute arbitrary code during the early boot phase, prior to operating system initialization" (CERT/CC, 2026-06-17). Because the vulnerable binary travels with the boot media rather than the installed OS, any endpoint trusting the third-party UEFI CA is a candidate carrier even when its OS is fully patched. Vendors named in CERT/CC's coordinated disclosure include Red Hat/CentOS, Oracle Linux, openSUSE, ROSA Linux, Baramundi Management Suite, Blancco/WhiteCanyon WipeDrive, PC-Doctor Service Center, Spyrus WTGCreator, and Finland's Abitti exam-kiosk system — a long tail of Linux-distro, PC-diagnostic, disk-wipe and kiosk tooling that forked an old shim and never rebased onto upstream fixes. Microsoft revoked all 11 binaries in its 2026-06-09 Patch Tuesday dbx update; no in-the-wild exploitation has been reported, and ESET deliberately withholds indicators of compromise because the binaries are "present on thousands of systems that have never been compromised via these loaders."
Defender takeaway. This is a pre-OS-boot technique class, so runtime endpoint telemetry cannot see the exploitation step — the actionable control is inventory and firmware-state verification, not detection. Confirm the June dbx revocation is actually enrolled in firmware (firmware-level dbx updates frequently lag OS patching, and a machine can show a fully patched OS while its dbx is stale), sequencing the accompanying DB update before the DBX update where the vendor guidance calls for it to avoid bricking dual-boot or recovery partitions, then audit Linux and dual-boot EFI System Partitions for forked shim binaries at version ≤ 0.9. Triage: legitimate dual-boot recovery media and vendor diagnostic USB sticks are exactly the artifact class this bug lives in, so a hunt for "old shim present" will surface real, benign, stale tooling — the discriminator is not the shim's presence but whether the dbx revocation has been enrolled in that device's firmware: a revoked-but-present shim is inert, an unrevoked one is the exposure.
the revocation check used the value from the signature header, while the signature verification function used the value from the PE header
An attacker needs no complicated exploitation primitives – only a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims work.
An attacker could exploit these vulnerable shim bootloaders using a Bring Your Own Vulnerable Driver (BYOVD)-style technique to execute arbitrary code during the early boot phase, prior to operating system initialization, thereby bypassing Secure Boot protections.
Defender actions
- Confirm Microsoft's 2026-06-09 dbx (Forbidden Signature Database) revocation is enrolled in firmware across the Windows and Linux/dual-boot fleet — dbx enrollment commonly lags OS patching — and audit EFI System Partitions for forked/vendored shim binaries at version ≤ 0.9 or lacking SBAT (the sei-vsarvepalli/uefi-dbx-audit script and Microsoft's secureboot_objects dbx manifest are the concrete artifacts to diff against).
ATT&CK mapping
2 techniques mapped from the cited reporting · MITRE ATT&CK v19.1
Persistence TA0003
T1542.003Pre-OS Boot: Bootkit
Adversaries may use bootkits to persist on systems. A bootkit is a malware variant that modifies the boot sectors of a hard drive, allowing malicious code to execute before a computer's operating system has loaded. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
Stealth TA0005
T1542.003Pre-OS Boot: Bootkit
Adversaries may use bootkits to persist on systems. A bootkit is a malware variant that modifies the boot sectors of a hard drive, allowing malicious code to execute before a computer's operating system has loaded. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
Defense Impairment TA0112
T1553.006Subvert Trust Controls: Code Signing Policy Modification
Adversaries may modify code signing policies to enable execution of unsigned or self-signed code. Code signing provides a level of authenticity on a program from a developer and a guarantee that the program has not been tampered with. Security controls can include enforcement mechanisms to ensure that only valid, signed code can be run on an operating system.
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.