# Forgotten UEFI shims undermining Secure Boot

11 forgotten Microsoft-signed UEFI shims (v0.9 and below) let attackers bypass Secure Boot on any machine trusting the Microsoft third-party UEFI CA, enabling bootkit deployment.

- Payout: Research
- Severity: high
- Program: UEFI shim
- Found by (vendor credit): Martin Smolar of ESET
- Write-up by: ESET Research
- Disclosed: 2026-07-14
- CVE: CVE-2026-8863, CVE-2026-10797
- Write-up quality: 8/10
- Original: https://www.welivesecurity.com/en/eset-research/forgotten-uefi-shims-undermining-secure-boot/
- Library page: https://bugbountylibrary.com/r/blog%3Awelivesecurity-com-en-eset-research-forgotten-uefi-shims-undermining-secure-boot
- Tags: area:cloud domain:infra impact:integrity impact:privesc kind:research platform:threat-intel sev:high tech:linux tech:windows technique:legacy-endpoint technique:source-review vuln:auth-bypass vuln:signature-replay

**Target:** UEFI shim bootloader / second-stage GRUB 2 bootloader
**Root cause:** Old Microsoft-signed shims (<=0.9) lack MokListX denylist enforcement and SBAT, trust vulnerable GRUB 2 binaries (e.g. CVE-2015-5281 multiboot), and diverge on WIN_CERTIFICATE vs PE-header signature length so revocation checks compare bogus data.
**Steps:**
1. Obtain a vulnerable Microsoft-signed shim (e.g. Abitti 1 v0.8, RHEL 7.2 v0.9, Oracle Linux shim) from the CERT/CC list.
2. Build an unsigned multiboot2-compliant ELF kernel image with required headers.
3. Copy shim, a trusted-but-vulnerable GRUB 2 binary, and the custom image to the EFI System Partition.
4. Boot; shim validates GRUB 2 against embedded cert without consulting SBAT/MokListX.
5. At GRUB 2 prompt run `multiboot2 <image>` to load and execute unsigned code with Secure Boot enabled.
6. Alternatively tamper WIN_CERTIFICATE length so revocation check reads bogus signature, bypassing dbx/MokListX cert revocation.
**How found:** Researchers audited the shim-signing ecosystem, noting pre-2017 shims are undocumented; examined embedded vendor/shim certs and trusted second-stage binaries with timestamps 2013-2025, spotting old GRUB 2 and pre-feature shim versions, and code-read the d241bbb commit revealing the WIN_CERTIFICATE length divergence.
**Exploitation:** Attacker with local/ESP write access brings their own vulnerable shim plus a GRUB 2 binary it still trusts, places them on the ESP, and uses GRUB's multiboot2 command (or a revoked-cert binary via the length-mismatch bug) to execute unsigned code during boot, installing a UEFI bootkit (BlackLotus, Bootkitty, HybridPetya) despite Secure Boot.
**Escalation:** Chains old shim trust with known GRUB 2 vulnerabilities (BootHole, CVE-2015-5281) and pre-SBAT/pre-MokListX shims to defeat newer revocation mechanisms, then persists via MOK NVRAM abuse.
**Insight:** When a signed first-stage loader delegates trust to embedded certs, enumerate every binary those certs sign and check their build dates against known CVEs; also diff which length/field each security check trusts versus the verifier—divergent parsing of the same structure is a reliable revocation bypass.