Security researchers at ESET have identified 11 old UEFI shim bootloaders, all signed by Microsoft, that can be abused to bypass Secure Boot on most systems using the modern firmware standard. Two CVEs, CVE-2026-8863 and CVE-2026-10797, have been assigned to track the issue.

Shims are small, trusted components that bridge a motherboard’s UEFI firmware and the operating system, most commonly a Linux distribution. By relying on a Microsoft-signed shim, Linux vendors can boot with Secure Boot enabled without embedding individual keys into a machine’s NVRAM. The shim then vouches for bootloaders, kernels, and other components later in the chain.

According to ESET, the flagged shims, mostly version 0.9 or earlier, remained signed and trusted within the Secure Boot chain long after fixes existed in the open source shim project, because not every vendor updated its own bootloader packages. Signing and compilation timestamps on the applications trusted by these shims range from 2013 to 2025, suggesting many binaries carried known, publicly documented vulnerabilities, including issues similar to the GRUB2 flaw known as BootHole.

The vulnerable shims can be exploited to bypass Secure Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Corporation UEFI CA 2011 third-party certificate, regardless of which operating system is installed. Attackers do not need physical access to a specific vulnerable device; they could also introduce their own malicious but still-trusted shim to any system that has enrolled the Microsoft certificate.

An attacker who successfully exploits one of these applications can execute untrusted code during the boot process, enabling deployment of bootkits or other malware even with Secure Boot turned on.

Remediation Guidance

ESET reported its findings to CERT/CC in February 2026. Microsoft responded by revoking the vulnerable applications and adding them to the UEFI DBX (Forbidden Signature Database) as part of the June 2026 Patch Tuesday release.

CERT/CC cautions that administrators must update the signature database (DB) before applying the DBX revocations. In practice, this means deploying updated trusted boot applications and certificates first, then rolling out the revocation list; doing it out of order can cause systems to reject legitimate, newly updated boot components.

  • Enterprises, cloud operators, and virtualization providers managing large fleets should prioritize validating and deploying these updates before rollout of the revocation list.
  • Because shim signing and vetting has only been consistently documented since 2017, older approved shims may remain untracked, leaving additional legacy exposure that isn’t yet fully mapped.

Organizations running mixed Linux and Windows fleets on UEFI hardware should audit their boot chains for outdated shims and confirm DBX updates have been applied in the correct sequence to avoid boot failures.