Eleven forgotten boot loaders let attackers walk around Secure Boot

On 14 July 2026 ESET published its discovery of eleven old boot loaders signed by Microsoft that were still trusted. All are so called shims in version 0.9 or older, and they can be used to bypass Secure Boot on machines where Microsoft's third party certificate is enrolled. Microsoft revoked them on 9 June 2026, in the advisory for CVE-2026-8863, which the company rated important with a CVSS score of 7.8. The discovery was made by ESET researcher Martin Smolár, and CERT/CC has issued a note of its own.

What happens technically

A shim is a small first stage boot program that Microsoft signs once, and which then acts as a trust anchor of its own further along the boot sequence. The arrangement exists because every Linux distribution builds its own boot files, and having each of them signed directly would be impractical. The chain of trust runs in three steps: the firmware checks the shim against the Microsoft certificate, the shim checks the next stage against its own embedded vendor certificate, and that stage checks the kernel against the same one. The weakness is that an old shim is still accepted by the firmware. The attacker does not need the distribution in question installed at all, and can bring along a copy of the old file and place it on the machine's boot partition.

ESET describes four routes onwards. Old shims still trust second stage loaders with known holes, among them a GRUB 2 file affected by CVE-2015-5281. Shims older than version 0.9 enforce only the allow list for owner signing keys and not the deny list, so an organisation that believed it had blocked an old key had not. Support for the version based revocation mechanism SBAT arrived only in shim version 15.3, so every one of the reported files ignores that mechanism entirely. ESET also found one new flaw, CVE-2026-10797, where the signature length is read from two different places so that the revocation check itself can be fooled. That identifier is used by ESET and CERT/CC, but as of 18 August 2026 it is not published in NVD or in the CVE record. The consequence is that code can run before the operating system starts, and therefore survive both a reinstallation and a disk replacement. The attack requires local administrator privileges or physical access, according to Microsoft. None of the sources reports observed exploitation, and ESET deliberately withheld indicators of compromise. Note one discrepancy as well: Ars Technica gives CVE-2015-5381 for the GRUB 2 hole, while ESET gives CVE-2015-5281, and the latter is the one that actually describes a Secure Boot bypass.

What this means for you if you run Linux machines

Windows machines receive this revocation automatically. Your Linux machines do not. They have to fetch the updated deny list themselves, and ESET points to the Linux Vendor Firmware Service as the route. Our assessment is that this is the practical dividing line in the case, and that it lands on exactly the machines that rarely top anybody's list: build servers, lab machines, equipment at unstaffed sites and everything that was set up once and has worked ever since. The requirement for local administrator or physical access does not turn this into a theoretical exercise. Brief physical access to a powered off machine is precisely what Secure Boot is meant to protect against.

The uncomfortable question is how many such files still exist. Nobody knows, and transparency into the signing programme arrived only in 2017. Revocation based on file hashes scales poorly, because the list holds around 32 kilobytes, and that is exactly why the version based mechanisms were built. If you are responsible for machines handled by others, for instance during service or disposal, it is worth noting that two of the affected products are wiping and diagnostic tools. And one warning before you begin: CERT/CC writes that updating the deny list can render machines unbootable, and that order matters. Update the allow list before the deny list.

Berigo recommends

• Roll out the updated deny list on your Linux machines. Windows receives it automatically, Linux does not.
• Test on a handful of machines first. CERT/CC warns that the update can render machines unbootable, and that the allow list must be updated before the deny list.
• Check whether Secure Boot is switched on at all across your estate, and whether Microsoft's third party certificate is enrolled.
• Include physically exposed machines in the assessment: laptops on the road, equipment at unstaffed sites and machines away for service or disposal.
• Remember that a compromise at this level survives reinstallation. Recovering such a machine is a firmware matter rather than an operating system matter.