ESET identified 11 old Microsoft-signed UEFI shim bootloaders that can bypass UEFI Secure Boot on systems trusting the Microsoft Corporation UEFI CA 2011 certificate. Microsoft revoked the vulnerable shims in its June 9, 2026 Patch Tuesday update, closing a path that could enable bootkit deployment such as BlackLotus, Bootkitty, and HybridPetya. #Microsoft #CERTCC #BlackLotus #Bootkitty #HybridPetya
Keypoints
- ESET found 11 outdated UEFI shim bootloaders at version 0.9 and below that can bypass UEFI Secure Boot.
- The issue affects any UEFI-based system that trusts the Microsoft Corporation UEFI CA 2011 third-party certificate, regardless of the installed OS.
- Attackers can bring their own vulnerable shim binaries to a target machine and execute untrusted code during system boot.
- The vulnerable shims can be used to deploy malicious UEFI bootkits, including Bootkitty, HybridPetya, and BlackLotus.
- Microsoft revoked the affected binaries in the dbx update delivered with the June 9, 2026 Patch Tuesday.
- The attack surface is broader because the shims trust second-stage bootloaders, especially GRUB 2, which may also contain known vulnerabilities.
- Older shims may miss newer protections such as MOK denylist enforcement and SBAT, making them useful for bypassing later revocation mechanisms.
MITRE Techniques
- [T1542.001 ] Pre-OS Boot: Firmware – The attacker abuses vulnerable UEFI shim bootloaders during startup to bypass Secure Boot and load untrusted code before the operating system (‘execute untrusted code during system boot’).
- [T1068 ] Exploitation for Privilege Escalation – A vulnerable signed GRUB 2 binary is used to load a crafted unsigned multiboot2 kernel image and run it at boot (‘allows local users to bypass intended Secure Boot restrictions and execute non-verified code via a crafted (1) multiboot or (2) multiboot2 module’).
- [T1553.001 ] Subvert Trust Controls: Modify Firmware Secure Boot Policy – The attack relies on trusted but outdated shims that bypass Secure Boot trust and revocation enforcement (‘bypass UEFI Secure Boot on any UEFI-based machine’).
- [T1562.001 ] Impair Defenses: Disable or Modify Tools – Older shims ignore MOK denylist and SBAT revocations, weakening security controls that should block vulnerable components (‘it ignores MokListX’ / ‘it does not read the SbatLevel revocation policy’).
- [T1027 ] Obfuscated Files or Information – The revocation bypass leverages tampering with WIN_CERTIFICATE data so the shim validates bogus data instead of the real signature (‘tampering with the second-stage bootloader’s WIN_CERTIFICATE structure’).
- [T1195.001 ] Supply Chain Compromise: Compromise Software Dependencies and Development Tools – The threat depends on Microsoft-signed third-party shims and trusted second-stage bootloaders distributed through normal signing channels (‘submitted to Microsoft for signing’).
Indicators of Compromise
- [File hashes ] Revoked UEFI shim bootloaders in Microsoft dbx – AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961, 7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10, and other 9 hashes
- [CVE IDs ] Vulnerable shim issues tracked by ESET and Microsoft – CVE-2026-8863, CVE-2026-10797
- [File name / media ] Example vulnerable Oracle Linux boot media containing affected GRUB 2 – V74844-01.iso
- [Certificate thumbprint ] Oracle Corporation certificate used to sign a vulnerable GRUB 2 binary – 2E434A724B4759C981E4189AA5AD3D635096DD2F
- [Registry path ] Windows location exposing SBAT revocation status – HKLMSYSTEMCurrentControlSetControlSecureBootSBATSbatLevel
- [Boot variables / database names ] UEFI revocation and trust stores referenced for detection – db, dbx, MokList, MokListX, SbatLevel, SbatLevelRT
Read more: https://www.welivesecurity.com/en/eset-research/forgotten-uefi-shims-undermining-secure-boot/