"As the vulnerable shims are part of legitimate software packages that are potentially present on thousands of systems that have never been compromised via these loaders, we are not providing indicators of compromise to avoid massive misidentification," ESET said.
Eleven Microsoft-signed shims create a broad attack surface
ESET researchers disclosed that 11 UEFI shim bootloaders, all signed under the Microsoft Corporation UEFI CA 2011 third-party certificate and all version 0.9 or below, carry vulnerabilities that enable Secure Boot bypass. Because each shim was signed by Microsoft, any UEFI firmware that trusts that third-party certificate will accept those shims regardless of the installed operating system. The vulnerabilities were reported to the CERT Coordination Center (CERT/CC) in February 2026.
Old second-stage loaders — mostly GRUB 2 — do the heavy lifting
The danger stems less from any single shim bug than from the age and trust relationships of the second-stage bootloaders the shims accept, largely GRUB 2 builds. ESET observed signing timestamps for the trusted binaries ranging from 2013 to 2025 and noted that older GRUB 2 builds carry well-documented flaws. In a demonstration using the Oracle Linux shim, ESET showed that the shim trusted a GRUB 2 binary vulnerable to a 2015 flaw that allows unsigned code to load via crafted multiboot modules.
Exploitation, ESET emphasized, does not require memory corruption or reverse engineering. An attacker can produce an unsigned kernel image, place it alongside the vulnerable shim and the old GRUB 2, and boot it with a single command at startup — enabling untrusted code to run during boot and opening the door to UEFI bootkits such as Bootkitty, HybridPetya and BlackLotus even with Secure Boot enabled.
MOK denylist and SBAT protections are absent on these shims
Protections introduced in later shim versions do not help systems still using the vulnerable shims. Enforcement of the Machine Owner Key (MOK) denylist arrived only in shim version 0.9; earlier shims ignore that denylist, allowing binaries that administrators believe revoked to be loaded. Likewise, Secure Boot Advanced Targeting (SBAT), a version-based revocation system introduced in shim 15.3, is never checked by these older shims. ESET highlighted these gaps as a key reason older shims can be used to bypass newer revocation mechanisms.
Vulnerability tracking, CVEs and vendor responses
Two CVE identifiers — CVE-2026-8863 and CVE-2026-10797 — cover the shims ESET reported. Microsoft revoked the vulnerable binaries in the dbx update shipped with its June 9 Patch Tuesday. According to ESET's advisory, Windows machines should receive that revocation automatically; Linux users can obtain the revocation via the Linux Vendor Firmware Service (LVFS).
Because the vulnerable shims are embedded in legitimate software packages that may be present on thousands of otherwise uncompromised systems, ESET declined to publish indicators of compromise to avoid misidentification. Instead, ESET directed defenders to follow the guidance in its "Protection and detection" section.
What this means for Linux users, Windows systems, and security teams
- Linux users: The immediate path to mitigation is to retrieve the dbx revocation through the Linux Vendor Firmware Service and confirm shim updates where available. Systems relying on older distribution images or vendor-supplied firmware are at higher risk because older shims may remain installed.
- Windows systems: Microsoft included the revocations in its June 9 Patch Tuesday dbx update, and that update should be delivered automatically to Windows machines that accept it.
- Security teams and defenders: ESET's decision not to publish IOCs shifts emphasis to patching and revocation. Teams should inventory shim versions where possible and apply the dbx update or LVFS revocation; they should also recognize that later protections such as MOK denylist enforcement and SBAT will not affect shims older than the versions that introduced those features.
One of the clearest practical problems ESET flagged is visibility. Shim submissions were cataloged transparently only beginning in 2017, and "no one can say how many older, still-trusted shims remain in circulation." Microsoft’s revocation step on June 9 addresses the known binaries, but the persistence of decade-old shims and the trust they inherit from a widely accepted third-party certificate leave an unresolved inventory question: how many machines still accept those legacy shims at boot?
Original reporting: https://www.infosecurity-magazine.com/news/uefi-shims-secure-boot-bypass/
