“An attacker exploiting one of these vulnerable applications can execute untrusted code during system boot, enabling deployment of malicious UEFI bootkits or other malware,” ESET researcher Martin Smolár wrote in a report published July 2026.
ESET discovery and the attack risk
Slovak security firm ESET published findings that 11 Microsoft-signed Unified Extensible Firmware Interface (UEFI) applications — older versions of the open-source shim bootloader — can be abused to bypass Secure Boot on most modern firmware platforms. The exploitation allows arbitrary code execution during the earliest phase of system startup, which ESET warns can enable “deployment of malicious UEFI bootkits or other malware.” The report names Bootkitty, HybridPetya, and BlackLotus as examples of UEFI bootkits that could be deployed via this vector.
Affected vendor bootloaders and exact versions
ESET and CERT/CC enumerated the specific vendor bootloaders built from vulnerable shim releases. The list in the advisory identifies the following products and shim loader versions:
- Spyrus WTGCreator from UEFI shim loader (0.7 or lower)
- RedHat RedHat Enterprise Linux (7.2) from UEFI shim loader (0.9)
- RedHat CentOS (7.2) from UEFI shim loader (0.9)
- Baramundi software baramundi Management Suite (up to 2024R1) from UEFI shim loader (0.8)
- WhiteCanyon/Blancco WipeDrive (8.0.0 through 8.1.3) from UEFI shim loader (0.7)
- Finland's Matriculation Examination Board Abitti 1 (1.0) from UEFI shim loader (0.8)
- NTC IT ROSA, LLC ROSA Linux (R10, R9) from UEFI shim loader (0.9)
- Oracle America, Inc. OracleLinux (7.2) from UEFI shim loader (0.9)
- PC-Doctor, Inc. PC Doctor Service Center (15, 16) from UEFI shim loader (0.9)
- OpenSuse OpenSuse UEFI Shim loader (0.9)
- OpenSuse OpenSuse Shim (2.1) from UEFI Shim loader (0.9)
How the shim bypass works: MOK, BYOVD, and SBAT
The shim is designed to bridge UEFI firmware and Linux boot components: firmware validates the shim against a Microsoft-signed certificate in the firmware’s trust store, the shim validates a second-stage loader (typically GRUB 2) against an embedded vendor certificate, and GRUB 2 validates the kernel with that same vendor certificate. ESET explained that older shims built from shim project releases "mainly from version 0.9 and earlier" remain signed and trusted unless explicitly revoked by hash.
Attackers can exploit this trust model in several ways. One path is to replace a current shim with an older Microsoft-signed shim binary that is still trusted by the firmware: because the Machine Owner Key (MOK) allowlist can authorize unsigned drivers while Secure Boot is active, an attacker using an older shim can bypass MOK denylist enforcement and then load vulnerable binaries without restriction. ESET described this as effectively requiring “no complicated exploitation primitives – only a copy of an old, still-trusted, but unrevoked shim binary.”
The advisory also highlights the bring your own vulnerable driver (BYOVD) technique as a vector to run arbitrary code during early boot, and notes that the attack can subvert Secure Boot Advanced Targeting (SBAT), which is intended to update minimum acceptable generations of boot components to block older, vulnerable versions.
CVE tracking, CERT/CC advice, and Microsoft actions
The issues are tracked under CVE-2026-8863 and CVE-2026-10797; the latter refers to “a long-patched issue in shim that allowed the certificate-based revocation mechanism to be bypassed by modifying the second-stage bootloader's signature header,” the report states. CERT Coordination Center (CERT/CC) warned that many vendor-specific bootloaders “have not been updated to address vulnerabilities in the upstream project after they became publicly known and fixed,” leaving signed, vulnerable bootloaders trusted by Secure Boot systems.
Microsoft responded by revoking the affected upstream shim bootloaders as part of its June 2026 Patch Tuesday update following responsible disclosure earlier in February 2026. Separately, the Microsoft-signed third-party UEFI certificate authority “Microsoft Corporation UEFI CA 2011” expired on June 27, 2026 and has been replaced by “Microsoft UEFI CA 2023” and “Microsoft Option ROM UEFI CA 2023.” ESET cautioned, however, that certificate expiration “has no bearing on the Secure Boot verification process as long as the bootloaders signed with the expired certificate are not explicitly revoked by hash.”
What this means for technologists, procurement leaders, and end users
- Technologists and security teams: inspect firmware trust stores, confirm that vulnerable shim binaries are revoked where possible, and verify that vendor-supplied bootloaders have been rebuilt from patched upstream shim releases — CERT/CC noted many vendor bootloaders had not been updated.
- Procurement and IT leaders: review vendor statements for affected products in the enumerated list (for example, the RedHat, Oracle, OpenSuse, Baramundi, PC-Doctor, ROSA, Spyrus, WhiteCanyon/Blancco, and Abitti entries) to confirm patches or replacement images have been provided and revoked versions removed from distribution.
- End users and administrators: recognize that an attacker with administrative privileges or the ability to modify the boot process could abuse one of the listed shim bootloaders to bypass Secure Boot protections and execute code prior to the OS and security products loading; that early-boot persistence can survive reboots and, in some cases, OS reinstallation.
Microsoft’s revocation action in June 2026 and the expiration of the 2011 Microsoft UEFI CA are concrete steps, but ESET’s core point remains: unless vulnerable shim binaries are explicitly revoked by hash and vendor bootloaders rebuilt from fixed upstream code, the attack requires no new exploit — only an old, trusted binary. That reality leaves systems reliant on signed boot components exposed until revocation and vendor remediation are complete.
