ESET researchers have found that eleven Microsoft‑signed UEFI shims, which have never been revoked, can be abused to defeat Secure Boot on both Windows and Linux systems.
These shims are tiny bootloaders signed by Microsoft to allow non‑Microsoft operating systems to start when Secure Boot is enabled, and they are stored in the firmware’s allowed signature database. Ars Technica notes that the affected images contain outdated code that can be triggered to execute unsigned payloads, letting an attacker load a malicious bootloader without raising Secure Boot’s alarms.
Technical analysis shows the flaw lies in how the shims process certain configuration variables; by crafting a malicious payload that overflows a buffer or manipulates a verification routine, an attacker can cause the shim to hand over control to unsigned code. No CVE has been assigned yet, but the behaviour is consistent across all eleven images, meaning the risk is uniform regardless of which shim a system uses.
Although no active exploitation has been observed in the wild and no threat actor has been linked to the issue, the fact that the shims remain present in the UEFI revocation lists means that anyone with administrative or physical access can replace them or trigger the vulnerability with little effort. The Hacker News reports that this contrasts with the usual assumption that Secure Boot blocks unsigned firmware unless a valid signature is present.
The incident raises questions about the lifecycle management of third‑party bootloaders that rely on Microsoft’s signature, highlighting a gap in the revocation process that leaves old, vulnerable components indefinitely trusted. It also emphasizes the importance of maintaining an up‑to‑date database of allowed signatures and monitoring firmware updates from OEMs.
Administrators should verify that their devices have received the latest UEFI firmware updates from the manufacturer, which include Microsoft’s revocation of the affected shims. They should also check the Secure Boot configuration to ensure that only current signatures are enabled, consider enabling measured boot and TPM‑based attestation to detect unauthorized changes, and regularly review boot logs for signs of unsigned loaders attempting to run during start‑up.