2026-07-14 · view entry permalink →
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.