UEFI shim bootloaders signed by Microsoft serve as trusted intermediaries allowing Secure Boot-enabled systems to load Linux distributions without requiring individual keys in motherboard NVRAM. However, at least 11 old shim versions, mainly from version 0.9 and earlier, remained signed and trusted despite containing vulnerabilities. These outdated shims could be exploited to bypass Secure Boot on any system trusting Microsoft's Microsoft Corporation UEFI CA 2011 certificate, regardless of the installed OS. The vulnerabilities stem from the continued trust in old, vulnerable binaries, some dating back to 2013, including those affected by known issues like BootHole in GRUB2. ESET reported these findings to CERT/CC in February 2026. Microsoft revoked the vulnerable shims in June 2026 Patch Tuesday by adding them to the UEFI DBX. CERT/CC recommends updating the trusted boot applications and certificates before deploying the revocation list to prevent boot failures. Enterprises and cloud providers should prioritize these updates to prevent execution of vulnerable or unsigned boot components. Since shims approved before 2017 are undocumented, some old vulnerable shims may still exist, posing ongoing risks.

The vulnerability allows attackers to bypass UEFI Secure Boot protections on any affected system that trusts Microsoft's UEFI CA 2011 certificate. This enables execution of untrusted code during the boot process, potentially allowing deployment of persistent bootkits and undermining the integrity of the system's secure boot chain. The issue affects systems regardless of the installed operating system. The continued trust in old vulnerable shims increases the attack surface and risk of compromise during system startup.

Microsoft revoked the vulnerable UEFI shim bootloaders in June 2026 by adding them to the UEFI Forbidden Signature Database (DBX). System administrators should first update the signature database (trusted boot applications and certificates) before applying the DBX revocations to avoid boot failures. Enterprises, virtualization providers, and cloud operators managing large-scale deployments should prioritize validating and deploying these updates promptly. Failure to follow the recommended update order may cause systems to reject newly updated boot components. No additional vendor patches are indicated beyond the revocation and DBX update process.