CVE-2026-8863 breaks Secure Boot
Did you know your machine can be protected and vulnerable at the same time?
Eleven old, forgotten shims were breaking Secure Boot on any UEFI machine.
ESET discovered that these bootloaders, signed by Microsoft years ago, were never revoked. Any attacker could bring their own copy and use it without needing special system access.
There was no need to exploit any new flaw or have the affected software installed. It was enough to copy the vulnerable shim to the EFI partition and reboot.
The perfect weapon needs no new vulnerabilities or complex exploits.
ESET identified 11 UEFI shims signed by Microsoft at version 0.9 and below that were never revoked. These bootloaders act as a gateway to the boot process: if Microsoft signed them once, the firmware still considers them trusted. An attacker only needed to copy one to the EFI partition and reboot. Secure Boot would not stop it, because the binary carried the correct signature.
No new CVE, no sophisticated exploit, no barriers.
From those old shims it was possible to deploy bootkits such as Bootkitty, HybridPetya, or BlackLotus even on fully patched systems. Shims prior to version 15.3 ignore SBAT, the version-based revocation mechanism, and load GRUB 2 without checking whether it has been revoked. The GRUB 2 instances trusted by those shims had accumulated vulnerabilities since 2013, including CVE-2015-5281.
Every forgotten shim was a master key with no expiration date.
Microsoft revoked all 11 shims in the Patch Tuesday of June 9, 2026, following the coordinated disclosure that ESET reported to CERT/CC in February. But the question that remains is how many shims signed before 2017 are still out there without anyone having catalogued or retired them.
What is not catalogued is not revoked.
The signing process became more transparent in 2017 with the shim-review repository, where manufacturers submit their binaries before Microsoft signs them. Everything prior to that is uncharted territory: no one can say how many old shims are still trusted by the firmware.
The problem goes beyond these eleven cases.
The shims come from diagnostic tools, Linux distributions, and UEFI utilities of all kinds. One belonged to Finland’s Abitti software; another came from Oracle Linux 7.1. They were legitimate components that were simply never retired. The BootHole incident in 2020 already demonstrated that hash-based revocation has a physical limit that complicates withdrawing binaries at scale.
Shims prior to 0.9 ignore the MOK blacklist.
An administrator who revoked a compromised certificate by adding it to MokListX believed they were protected. But if an attacker replaced the updated shim with an older version 0.8 one, that shim ignored the blacklist entirely and loaded the vulnerable binaries without restriction. The revocation was nullified without anyone noticing.
CVE-2026-10797 went almost a decade without an official CVE identifier.
The flaw was fixed in an upstream repository commit years ago, but never received a CVE. It allows manipulation of the WIN_CERTIFICATE structure of a bootloader so that the shim compares revocation against fake data, ignoring whether the real certificate is blocked.
The certificate expired, but the risk did not.
The Microsoft Corporation UEFI CA 2011 certificate expired in June 2026, but that changes nothing in Secure Boot. If the certificate remains in db and is not in dbx, all binaries it signed are still trusted. Microsoft continued signing new requests with that certificate until the last day before its expiration.
Expiration is not real protection.
Applying the latest Microsoft dbx revocation updates is the immediate step. On Windows they are installed automatically; on Linux, through the Linux Vendor Firmware Service.
What you can do
- ✓Install the latest Microsoft dbx revocation updates.
- ✓On Linux, verify the status with the uefi-dbx-audit script.
- ✓Check the revocations applied on Windows using an elevated PowerShell session.
How many forgotten shims are still signed and active on my machine right now?
Security is not improvised, it is audited. At Nacata Security we detect vulnerabilities and protect your company, because a single flaw can cost you everything you have built.
Related articles
BitLocker Takes Companies Hostage
Can you imagine arriving at work and being unable to open a single company file?
MessiahGPT Forges Unlimited Malware
Did you know that buying ready-made ransomware costs less than your streaming subscription?
Printers distributed ransom notes
Can you imagine arriving at work to find your computer locked with no explanation?
Talos opens its secret files
Have you ever wondered what really happens when an attack hits?
PHP fixes 3 critical vulnerabilities
Does your web application talk to a database or process files uploaded by users?
Nacata Security, reach out to us anytime
We are Nacata Security, get to know us
web: nacata.io
email: info@nacata.io
Phone: 919930793
LinkedIn: Nacata Security
The ecosystem of malicious actors and the intelligence gathered about them: APT groups and their attribution, ransomware gangs, law enforcement operations and arrests, dark web markets, threat intelligence reports and the geopolitical backdrop of cybercrime.
RATING
7.3
Who are we?
At Nacata Security we are an offensive cybersecurity company specialized in audits and penetration testing.
We detect, assess and help mitigate the vulnerabilities of your systems, networks and applications before a real attacker exploits them, offering 360º defense tailored to each client.
We’d be glad to get in touch with you for whatever you need.