Eset Finds 11 Microsoft-Signed First-Stage Bootloaders Are Vulnerable to Abuse
Tiffany Wang •
July 14, 2026
Eset identified 11 Microsoft-signed legacy UEFI shim bootloaders with a vulnerability that enables attackers to bypass Secure Boot and install bootkits. (Image: Shutterstock)
Some Microsoft-signed first-stage bootloaders have grown vulnerable with age. Their entire job to establish trust can be exploited to bypass Secure Boot protections, researchers found.
See Also: Beat the Breach: Outsmart Attackers and Secure the Cloud
Each of the 11 small pieces of code called shims, identified by security firm Eset, can be used to execute untrusted code during system boot on millions of machines using the modern firmware architecture Unified Extensible Firmware Interface that still trusts the old shims’ Microsoft certificate.
The vulnerability in shims at or below version 0.9, tracked as CVE-2026-8863 and CVE-2026-10797, enables attackers to deploy malicious bootkits, such as Bootkitty, HybridPetya or BlackLotus, before the operating system loads, even when UEFI Secure Boot is enabled. CVE-2026-8863 is listed as a high severity flaw, with a CVSS v3.1 base score of 7.8 assigned by the CISA Authorized Data Publisher.
Although Microsoft has revoked the mistrusted shims found by researchers, attackers can bring their own copy of the vulnerable shims to any UEFI system that still trusts the Microsoft third-party UEFI certificate, spreading damage beyond systems with the affected software.
A shim acts as a bridge between the UEFI firmware and the operating system, according to CERT Coordination Center. It is signed with the “Microsoft Corporation UEFI CA 2011” certificate widely used for third-party boot components to run under Secure Boot.
“An attacker could exploit these vulnerable shim bootloaders using a bring your own vulnerable driver-style technique to execute arbitrary code during the early boot phase, prior to operating system initialization, thereby bypassing Secure Boot protections,” CERT/CC said.
Once the firmware loads the shim and validates its signature, the shim transfers control to second-stage bootloaders that “extend the trust chain even further,” said Eset Senior Malware Researcher Martin Smolár. A shim can trust anywhere from a few to up to 100 second-stage binaries.
“Exploitation of each reported shim is not just about a single bug or two that can be found in these old shims directly,” Smolár said. “In fact, the attack surface is extended by the shims’ trusted, second-stage bootloaders, mostly GRUB 2, which – like the shims themselves – may include outdated versions with known vulnerabilities.”
One Oracle Linux shim, for example, trusted a binary vulnerable to CVE-2015-5281, a Secure Boot bypass flaw that allows local users to execute unverified code through a crafted configuration file.
Signing timestamps of the binaries trusted by the revoked shims span from 2013 to 2025, Smolár said, meaning they could be old enough to fall for known vulnerabilities such as BootHole, which allows a privileged attacker to bypass Secure Boot protection through Grub 2 in Linux distributions.
While new improvements were introduced to shims over the years, many third-party vendors have taken available versions of the shim source code that can be outdated and vulnerable to build their own binaries.
For example, an older Microsoft-signed shim can ignore the Machine Owner Key denylist introduced in newer versions, allowing attackers to load binaries signed with a revoked MOK certificate, Smolár said.
“What makes these old shims dangerous is not a novel vulnerability. It’s that no new vulnerability is needed to bypass UEFI Secure Boot,” Smolár said. “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. That is enough to bypass such an essential security feature as UEFI Secure Boot.”