Old UEFI Shims Pose Significant Risk to Secure Boot Protections
A recently uncovered vulnerability has exposed a significant number of systems to potential attacks, allowing attackers to bypass crucial Secure Boot protections. The issue lies in old Unified Extensible Firmware Interface (UEFI) shim bootloaders, which were signed by Microsoft and allowed Linux distributions to establish a trust model without requiring individual keys to be built into the motherboard’s NVRAM.
For those unfamiliar with UEFI shims, they’re small pieces of trusted software that bridge the gap between a computer’s motherboard firmware and operating system. They enable systems to boot securely, even when Secure Boot is enabled. However, old versions of these shims lingered around until recently, potentially putting millions of systems at risk.
ESET warns that 11 such old UEFI shims, primarily from version 0.9 and earlier, remained signed and trusted within the Secure Boot chain until they were revoked by Microsoft on June’s Patch Tuesday. These vulnerable shims could be exploited to bypass Secure Boot protections on any UEFI-based machine that trusts Microsoft’s third-party UEFI certificate authority (CA) certificate.
The issue is not just limited to the shims themselves but also extends to their trusted second-stage bootloaders. Attackers could bring their own vulnerable shims to systems that have enrolled the Microsoft third-party UEFI CA, allowing them to execute untrusted code during the boot process and deploy bootkits even when Secure Boot is enabled.
The affected shims were signed as far back as 2013, with some still trusted today. ESET notes that this continuous trust in old, vulnerable shims allows attackers to exploit numerous publicly known vulnerabilities, such as BootHole in the case of GRUB2.
Microsoft has taken steps to address the issue by revoking all vulnerable applications and adding them to the UEFI DBX (Forbidden Signature Database). System administrators are advised to update their signature database before applying DBX revocations. This involves updating trusted boot applications and certificates first, followed by deployment of the revocation list.
In practice, this means that enterprises, virtualization providers, and cloud operators managing large-scale deployments should prioritize validation and deployment of these updates to prevent the execution of vulnerable or unsigned binaries during physical or virtual machine startup.
The incident serves as a reminder of the importance of keeping software up-to-date and regularly reviewing trusted components. As shims have been signed and documented after vetting since 2017, it’s likely that many old, still-trusted shims may remain, potentially exposing systems to attacks.
As a precautionary measure, system administrators should verify their UEFI settings and ensure that all boot components are updated to the latest version. Regularly reviewing trusted software and firmware can help prevent such vulnerabilities from going unnoticed for extended periods.
Source: SecurityWeek — 2026-07-16