In February 2026, ESET researchers reported to CERT/CC a set of Secure Boot bypass vulnerabilities affecting Microsoft-signed UEFI shim bootloaders. The shim project is a small, Microsoft-signed bridge binary that allows Linux distributions and other non-Microsoft software to chain-load a second-stage bootloader (typically GRUB2) on systems with UEFI Secure Boot enabled, without requiring each vendor's key to be embedded directly in firmware. Because shim is Microsoft-signed against the widely deployed 'Microsoft Corporation UEFI CA 2011' certificate, any shim binary bearing a valid signature under that CA is trusted by virtually every Secure-Boot-enabled PC shipped since 2012.

Over the shim project's lifetime, numerous vendors forked or vendored older shim releases (version 0.9 and earlier) into their own products -- PC diagnostic and recovery tools, disk-wipe utilities, enterprise management agents, Linux distribution installers, and exam/kiosk software -- without tracking upstream security fixes. ESET catalogued 11 distinct Microsoft-signed shim binaries, signed between 2013 and 2025, that remained deployable and trusted despite carrying multiple unpatched weaknesses:

1. Missing MokListX (MOK denylist) enforcement -- shims at or below version 0.9 predate the MokListX revocation feature entirely, so even though a victim machine's MokList (allow-list) may be current, the shim silently ignores any certificate-based deny entries pushed via MokListX. An attacker can therefore replace an up-to-date shim on the ESP with one of these old, still-validly-signed shims and have it re-trust certificates that the system owner explicitly revoked.

2. WIN_CERTIFICATE structure tampering (CVE-2026-10797) -- a signed PE (portable executable) binary's Authenticode signature records its length in two separate places in the image. The affected shims read one length field when performing the revocation/denylist comparison and the other length field when performing cryptographic signature verification. By crafting a WIN_CERTIFICATE structure where these two fields diverge, an attacker can make the revocation-check code compare against bogus padding data instead of the bootloader's real signature, causing certificate-based dbx/MokListX revocations to silently fail to match while the binary still verifies and boots. This bypass is scoped to certificate-based revocation entries; hash-based (Authenticode thumbprint) dbx entries are unaffected by CVE-2026-10797 itself, which is why Microsoft's June 9 remediation revokes the vulnerable shims by their PE Authenticode hash directly.

3. Absent SBAT (Secure Boot Advanced Targeting) awareness -- shims prior to upstream version 15.3 do not parse the .sbat PE section or evaluate the SbatLevel UEFI variable at all. SBAT was introduced specifically to allow fine-grained, per-component revocation of vulnerable second-stage loaders (e.g., GRUB2) without having to blacklist entire shim binaries by hash. A pre-15.3 shim will happily chain-load an SBAT-revoked GRUB2 build, reopening previously patched GRUB2 vulnerabilities.

4. Chaining to a known-vulnerable second-stage loader -- as a concrete demonstration, ESET showed that the Oracle Linux 7.1 installation media shim will trust and chain-load a bundled GRUB2 binary that is vulnerable to CVE-2015-5281, a decade-old flaw that lets an attacker supply a crafted multiboot/multiboot2 kernel module to execute unverified code, fully defeating Secure Boot's chain of trust.

Exploitation requires the attacker to place one of the vulnerable, still-Microsoft-signed shim binaries (and, where relevant, a matching vulnerable second-stage loader or crafted multiboot image) onto the target's EFI System Partition. This requires either local administrator/root privileges on a running system, or physical/console access sufficient to write to the ESP (e.g., booting from removable media or through a management-agent supply chain such as Baramundi or WipeDrive images). No remote network exploitation path exists; Microsoft rates the vulnerability class 'Important' with a base CVSS of 7.8 (local, low complexity, requires low-privilege access, high impact to confidentiality/integrity/availability of the trust chain) precisely because of this local/physical access requirement, distinguishing it from remotely wormable Secure Boot bypasses like BlackLotus (CVE-2023-24932) but placing it firmly in the 'evil maid' / insider / post-compromise persistence category, and a significant concern for supply-chain-delivered recovery and diagnostic media.

Microsoft coordinated disclosure with CERT/CC (VU#616257): ESET reported the findings on February 16, 2026; initial public disclosure was slated for May 19, 2026 and later deferred to align with the June 9, 2026 Patch Tuesday, at which point Microsoft added the 11 vulnerable shim PE Authenticode hashes to the UEFI Forbidden Signature Database (dbx) and published CVE-2026-8863 (UEFI Secure Boot Security Feature Bypass Vulnerability, CWE-1329 Reliance on Component That is Not Updateable) and CVE-2026-10797 (the WIN_CERTIFICATE dual-length-field revocation bypass). Microsoft's UEFI CA 2011 certificate itself separately expired on June 27, 2026, part of the broader industry migration to UEFI CA 2023. ESET published its full technical writeup on July 14, 2026. No comprehensive inventory exists of all shims signed before 2017, so ESET and CERT/CC caution that the true population of vulnerable, still-trusted shim binaries in the wild is unknown and likely larger than the 11 catalogued samples.

Remediation is DBX-update-driven: Windows systems receive the June 9, 2026 dbx update automatically via Windows Update; administrators can verify application with Microsoft-provided PowerShell hash-check commands. Linux systems obtain the same dbx entries via the Linux Vendor Firmware Service (LVFS)/fwupd and can audit their state with the community uefi-dbx-audit script. Because dbx updates are irreversible NVRAM writes that can, in rare firmware-bug cases, render a system unbootable, Microsoft and ESET both recommend staged testing before broad deployment. Organizations relying on legacy recovery media, kiosk/exam software (e.g., Finland's Abitti 1 platform), or vendored diagnostic tools built on old shim forks should inventory and update or retire that media, since a still-valid, un-revoked shim copy anywhere in the organization's asset pool remains a usable bypass tool regardless of the dbx update landing on the target endpoint's primary OS.