Microsoft Revokes 11 Legacy UEFI Shims: Secure Boot Bypassed via…

Eleven Microsoft-signed UEFI shim bootloaders allowed Secure Boot bypass on any trusting system. Revocation arrived with the June 2026 Patch Tuesday.

ESET identified 11 legacy UEFI shim bootloaders, version 0.9 or earlier, that for years enabled Secure Boot bypass on any system trusting the Microsoft Corporation UEFI CA 2011 certificate. Revocation landed on June 9, 2026, with Microsoft's Patch Tuesday, coordinated by CERT/CC following researcher Martin Smolár's report on February 16, 2026.

The certificate's own expiration on June 27, 2026, does not solve the problem: as long as a signed binary is not entered into the dbx by specific hash, it remains technically trusted regardless of the certificate's expiration date.

Key Takeaways

ESET identified 11 Microsoft-signed UEFI shims from 10 different vendors that allow Secure Boot bypass regardless of the installed operating system.
The mechanism requires no zero-day vulnerability: pre-0.9 shims ignore the MOK denylist and pre-15.3 shims ignore SBAT revocation, permitting unauthorized bootloaders to load.
Microsoft assigned CVE-2026-8863 with a CVSS 3.1 score of 7.8 per its Security Update Guide.
The Microsoft UEFI CA 2011 certificate, expired June 27, 2026, does not automatically block already-signed binaries: Secure Boot verification does not check the certificate expiration date in the db.

The Mechanism: Two Different Reads of the Same Signature

The core of the vulnerability documented as CVE-2026-10797 is a mismatch in reading the PE signature length. A signed binary records the signature size in two distinct header locations; affected shims read one position during the revocation check and the other during signature verification.

By manipulating the WIN_CERTIFICATE structure, an attacker directs the revocation check to the wrong bytes, causing a revoked binary to pass as valid. This bug was fixed upstream nearly a decade ago, but the old Microsoft-signed shims had never been revoked in the dbx.

MOK denylist enforcement arrived only with shim 0.9; SBAT support only with 15.3. Shims compiled before those thresholds ignore the corresponding revocations, leaving a structural gap in boot integrity verification.

"What makes these old shims dangerous is not a novel vulnerability, it's that no new vulnerability is needed to bypass UEFI Secure Boot" — ESET

Eleven Hashes in the dbx, But Uncertainty Remains

ESET published the complete list of 11 SHA256 PE Authenticode hashes, also confirmed in the CERT/CC advisory VU#616257. The affected shims belong to Spyrus, Red Hat, CentOS, baramundi, WhiteCanyon/Blancco, Finland's Matriculation Examination Board, NTC IT ROSA, Oracle, PC-Doctor, and openSUSE.

Every UEFI system with the Microsoft Corporation UEFI CA 2011 certificate in the db is affected, "regardless of the installed operating system," as ESET documents in its official blog. The vendor's original operating system need not be present.

According to Help Net Security / ESET analysis, "no one can say with confidence how many old, still-trusted shims remain." The source does not specify how many other pre-2017 shims remain unidentified and unrevoked, leaving the completeness of the mitigation an open question.

Revocation occurred on June 9, 2026, during Microsoft's Patch Tuesday. CERT/CC coordination began on February 16, 2026, the day of Smolár's initial report. The four-month gap between report and release reflects the complexity of a distributed revocation process across millions of systems.

BYOVD Attack: Bring Your Own Vulnerable Bootloader

Exploitation follows a Bring Your Own Vulnerable Driver pattern transposed to firmware: the attacker copies their own vulnerable shim to the target system, paired with a compatible second-stage loader. Help Net Security cites CVE-2015-5281 for the Oracle Linux shim as a historical example, but the principle applies to any bootloader the loaded shim accepts.

The result is pre-OS persistence that survives operating system reinstallation. Required privileges are local and administrative. Microsoft MSRC classifies CVE-2026-8863 with CVSS 3.1 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), severity Important, with assessment "Exploitation Less Likely" and status "Exploited: No".

ESET researcher Martin Smolár stated: "An attacker exploiting one of these vulnerable applications can execute untrusted code during system boot, enabling deployment of malicious UEFI bootkits or other malware."

What to Do Now

Priority actions derive from enterprise recommendations documented by CERT/CC:

Apply the dbx update from the June 9, 2026 Patch Tuesday through system vendor or OS update channels.
Verify that enterprise systems receive firmware updates distributed via vendor patch management programs.
Monitor affected vendor advisories for any bootloader- or firmware-specific updates.

The source does not specify manual verification procedures, nor does it recommend disabling third-party UEFI CA signing as a standard mitigation. The dbx update is the correct revocation vehicle.

Why This Matters

The case exposes a structural deficit in UEFI certificate governance: Microsoft signed components for years, and the shim-review repository has existed since 2017. The CA 2011 certificate, expired June 27, 2026, remains in the db of millions of systems because expiration triggers no automatic invalidation.

Revocation by hash in the dbx is the only effective mechanism, but it requires someone to systematically identify vulnerable binaries. Until 2026, 11 signed shims remained active despite vulnerabilities known for nearly a decade.

The source does not specify whether Windows 11 Secured-core PCs actually have third-party signing disabled as intended. It also does not specify how many Linux systems have yet to apply the dbx update, nor whether exploitation has occurred in the wild.

The problem remains open for any other pre-2017 shim not yet cataloged: trust in Secure Boot depends on dbx completeness, not on the absence of zero-day vulnerabilities.

Information verified against cited sources and current as of publication.

Sources

Sources and references