SURIQ
Secure Boot did not fail this month because someone forged a Microsoft signature. It failed because 11 bootloaders that Microsoft signed years ago were never taken off the guest list. ESET published research on July 14 showing that these old shim binaries, all validly signed under the Microsoft Corporation UEFI CA 2011 certificate, still boot on almost any UEFI machine that trusts that certificate, whatever operating system is installed. Microsoft revoked them in its June Patch Tuesday update on June 9. If your fleet has not taken that revocation, the door is open, and your software inventory is not how you find out.
Why "we do not run that software" is the wrong question
According to ESET's research, the 11 shims ship inside products including Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, openSUSE and ROSA Linux, plus utilities such as Blancco WipeDrive and PC Doctor Service Center. The reflex is to check that list, confirm none are installed, and move on. That reflex fails here.
Each of these binaries is signed by a certificate that nearly every UEFI machine keeps in its allow store, the one Secure Boot labels db. So an attacker does not need the original product. They carry their own copy of the old shim to any machine that trusts the Microsoft 2011 third-party CA, which is nearly every PC and server shipped with Secure Boot on. ESET researcher Martin Smolar makes this the core of the finding: exposure is not limited to hosts that have the affected software installed. Bring the shim, and the machine boots it.
That reframes the exposure question. It is not "do I run these distributions." It is "does my firmware still trust the Microsoft 2011 third-party CA, and is my revocation list current." For most fleets the answer to the first is yes and the answer to the second is unknown. Note also what this is not: it is not an initial-access bug. An attacker needs code execution and enough local privilege on the host to write to the EFI system partition first. The payoff is what comes after, a bootkit that loads beneath the tools meant to catch it and survives a full reinstall.
What the flaw actually is under the hood
Two identifiers cover the set, CVE-2026-8863 and CVE-2026-10797. The interesting one is CVE-2026-10797. An Authenticode-signed PE binary records the length of its signature in two separate places: the PE header data directory and the WIN_CERTIFICATE structure that wraps the signature itself. In the vulnerable shims, the revocation check and the signature verifier disagreed on which length to trust. One read the size from the signature header, the other from the PE header. That gap lets an attacker reshape the certificate structure and slide past certificate-based revocation. Upstream fixed this roughly a decade ago, it never received a CVE at the time, and the old signed binaries that carry the bug were never revoked.
The older shims also skip two revocation features defenders assume are doing their job. The Machine Owner Key (MOK) denylist is only enforced from shim 0.9, and Secure Boot Advanced Targeting (SBAT), the versioned revocation scheme, is not supported before shim 15.3. A pre-15.3 shim will happily load a GRUB 2 bootloader that SBAT already blacklisted, reopening old holes such as CVE-2015-5281. ESET reported no exploitation in the wild, and there is no public exploit. The danger is that none is required: an old, still-trusted, unrevoked shim is the whole primitive.
The dates matter here. The upstream code fix predates the CVE by years. Microsoft added the 11 binary hashes to dbx, the forbidden-signatures database, on June 9, 2026. The Microsoft Corporation UEFI CA 2011 certificate itself expired on June 27, 2026, and that changed nothing. A signature stays trusted until its hash is revoked in dbx, not when the signing certificate ages out. Expiry is a red herring; revocation is the only lever.
The same crack as BootHole and BlackLotus
Secure Boot's signature checking has held up well. Its revocation has not, and this is the third public reminder in six years. BootHole in 2020 forced a dbx update for a GRUB 2 buffer overflow. BlackLotus in 2023 abused signed but revocable boot components and pushed Microsoft to distribute new signing certificates. The fix each time has the same shape: add hashes to a denylist, then get that denylist onto every machine. The signing chain is strong. The revocation cadence is the weak joint, and attackers keep aiming at it because it is the part that lags.
The reason it lags is not laziness. A dbx entry is one-way and can lock out a host that still legitimately boots an old signed component: dual-boot setups, recovery and imaging media, some out-of-support distributions. Push the wrong revocation and you brick a boot path. So many teams stage dbx updates slowly or skip them, and that caution is exactly the exposure window an attacker counts on.
Push the June revocation, then prove it took
The fix already shipped in the June 9 dbx update. Applying it is step one. Confirming it landed on every host is the part most teams never close out. On Windows, read the current UEFI revocation state rather than assuming the update applied; on Linux, the Linux Vendor Firmware Service with fwupd delivers and reports dbx status. Treat "dbx current" as a tracked control with a number attached, the way you track patch level, not a one-time push you forget.
Before you roll it out broadly, test on the awkward hosts first: dual-boot machines, appliances that boot old signed media, and recovery or imaging workflows. A revocation that blocks a shim you still boot from will break that path, and that is the precise risk behind the industry-wide revocation lag. Stage it, verify it, then measure your coverage. Our security hardening guidance treats firmware and boot integrity as part of the host baseline, not a separate project.
How you would know a bootkit slipped in
A UEFI bootkit runs before the operating system by design, so any on-host scanner that starts after boot is looking in the wrong place. The signal is pre-OS integrity. Measured boot with a TPM records each stage of the boot chain into platform configuration registers, and remote attestation compares those measurements against a known-good baseline, flagging a boot chain that changed. That is how a swapped bootloader shows up, not a disk scan. A managed detection setup should pull boot-integrity and firmware-attestation events off the host and correlate them centrally, so one tampered machine stands out against the rest of the fleet. Map the activity to MITRE ATT&CK Pre-OS Boot (T1542) so the alert carries context, and fold it into your threat hunting baseline.
The list you own is the revocation list
Secure Boot is not broken. Treating it as a set-and-forget checkbox is. The signatures did their job for a decade; the failure was never revoking binaries that everyone knew were superseded. The allow list is Microsoft's to manage. The revocation list is yours, and it is only as current as your last dbx push. Go check when that was.