Summary
- ESET identified 11 Microsoft-signed UEFI shims capable of loading unauthorised pre-operating-system code.
- Microsoft revoked the affected binaries through its June Secure Boot database update.
- Protection depends on revocations reaching each device without breaking legitimate bootloaders, recovery media, or specialist systems.
ESET researchers have identified 11 old Microsoft-signed UEFI shim bootloaders that could be introduced onto modern systems to bypass Secure Boot and execute unauthorised code before the operating system starts.
The affected binaries are shim versions 0.9 and earlier, drawn from Linux distributions, diagnostics products, recovery tools, and other UEFI utilities. Although the software is old, its Microsoft signatures remain valid on systems that have not received the relevant revocation data.
An attacker does not need the original product or Linux distribution to be installed. A vulnerable shim can be brought onto any UEFI system that trusts the Microsoft Corporation UEFI CA 2011 certificate, introducing an older but authorised component into the boot chain.
The shims can then load vulnerable second-stage bootloaders, including historic versions of GRUB 2, and use previously known flaws to execute code that Secure Boot would normally reject. ESET said the technique could support UEFI bootkits operating below the visibility of conventional endpoint controls.
The issues are tracked as CVE-2026-8863 and CVE-2026-10797. ESET reported the findings to CERT/CC in February, and Microsoft added the affected binary hashes to the Secure Boot forbidden-signature database, known as dbx, through its 9 June update.
No exploitation in the wild has been reported. An attacker would generally need administrative privileges, physical access, or another means of modifying the system’s boot configuration, so the weakness does not provide a standalone route to remote compromise.
Once an intruder has obtained that level of access, code loaded before the operating system can interfere with the assumptions underpinning endpoint monitoring, credential protections, operating-system integrity, and recovery procedures. Persistence below the operating system can survive controls designed to inspect only conventional files and processes.
ESET’s technical analysis recommends applying Microsoft’s latest dbx updates. CERT/CC has also published a vulnerability note listing affected products and vendor responses.
Secure Boot revocation is more complex than ordinary application patching because a device must retain a valid replacement boot path after the vulnerable binary has been blocked. Applying a dbx update without checking bootloader compatibility can leave systems unable to start, particularly where older Linux distributions, recovery environments, specialist appliances, or custom boot configurations remain in service.
Large estates therefore need an ordered deployment process. Authorised boot components should be inventoried and updated before revocation data is extended across representative hardware, while recovery media and rollback procedures need to be tested against the revised trust store.
Devices that connect infrequently, remain outside central endpoint management, or perform specialised laboratory and industrial functions may not receive the update promptly. Firmware variation can further complicate deployment, even where systems nominally run the same operating system.
The affected shims demonstrate the long lifespan of trust decisions made across hardware and firmware supply chains. Software signed many years ago can remain acceptable to current devices after its internal components have become unsafe. Removing that trust requires coordination between Microsoft, software vendors, device manufacturers, operating-system suppliers, and asset owners.
The work also coincides with Microsoft’s broader transition away from parts of its older Secure Boot certificate infrastructure. Certificate replacement, bootloader updates, and revocation deployment may reach the same systems during overlapping maintenance periods, increasing the need for shared planning between endpoint, infrastructure, Linux, and hardware-management teams.
Secure Boot remains effective only where its allowlists, certificates, and revocations are maintained throughout the life of the device. Systems that miss the June dbx update may continue to trust vulnerable binaries even when the operating system itself is fully patched.
