Old Microsoft-signed UEFI shims allow Secure Boot bypass
Multiple old Microsoft-signed Linux UEFI shim bootloaders remain trusted by firmware and can be reused to load unsigned code before the operating system, bypassing Secure Boot. Microsoft revoked the affected binaries via the June 2026 DBX update.
- Vendor
- Microsoft (signed via Microsoft UEFI CA 2011)
- Product
- Linux UEFI shim loader (multiple vendors — RedHat, Oracle, OpenSUSE, ROSA, Baramundi, Blancco, Spyrus, PC-Doctor, Abitti)
- CVSS
- 7.8
- EPSS (exploit probability)
- N/A
- Status
- patched
- Published
CVE-2026-8863 is a Secure Boot bypass affecting multiple old Microsoft-signed Linux UEFI shim bootloaders. Per NVD, an attacker with administrative privileges or the ability to modify the boot process can substitute one of the vulnerable shims for the current one; because those older shims are still signed by the Microsoft Corporation UEFI CA 2011 and were not on the DBX until Microsoft’s June 2026 revocation, firmware happily loads them and hands control to their bundled bootloader, allowing arbitrary code to run before the operating system. This subverts both Machine Owner Key (MOK) enforcement and Secure Boot Advanced Targeting (SBAT) revocation.
Affected shim versions
Per ESET’s disclosure: shim 0.7 or lower (Spyrus WTGCreator, WhiteCanyon/Blancco WipeDrive 8.0.0–8.1.3), shim 0.8 (Baramundi Management Suite up to 2024R1, Finland Matriculation Board Abitti 1.0), and shim 0.9 (RHEL/CentOS 7.2, Oracle Linux 7.2, ROSA Linux R9/R10, PC-Doctor Service Center 15/16, OpenSUSE UEFI Shim loader 0.9 and Shim 2.1).
Fix
Microsoft revoked the affected shim binaries via the June 2026 Patch Tuesday DBX update. Systems that have applied that update — and that ship the update to firmware via fwupd, mokutil, LVFS, or the vendor’s own UEFI update path — reject the vulnerable shims at boot. Systems that haven’t applied it, or that applied the OS-level update but never pushed the DBX to firmware, remain exposed.
The separate expiry of the Microsoft Corporation UEFI CA 2011 certificate on 2026-06-27 does not by itself close this hole: expiry stops new signings, but firmware still trusts the CA for previously-signed binaries. Revocation via DBX is the actual mitigation.
What to do
Verify the June 2026 DBX update reached firmware (mokutil --list-new on Linux; the vendor’s firmware-update tool otherwise). See the article writeup for the audit angle and the CERT/CC note at VU#616257. Canonical Microsoft advisory: MSRC guidance for CVE-2026-8863.
