Eleven Old Microsoft-Signed UEFI Shims Enable Bypass of Secure Boot on Linux Systems Still Trusting Microsoft Corporation UEFI CA 2011

Eleven legacy UEFI shim bootloaders, all signed by Microsoft and dating back to version 0.9 or earlier, can be exploited to bypass UEFI Secure Boot on systems whose firmware still trusts the Microsoft Corporation UEFI CA 2011 certificate. The vulnerability allows an attacker who can place one of these old but validly signed shims into the boot chain to execute arbitrary code before the operating system starts, effectively turning a trusted loader into a vector for pre-OS compromise.

The risk is comparable to a BYOVD (Bring Your Own Vulnerable Driver) attack but occurs at the firmware level. An attacker does not need the original software that shipped the shim; it is sufficient for the firmware to accept the signature and for the attacker to modify the EFI partition, disk, or boot media. Because execution happens before the OS loads, traditional endpoint detection and response telemetry often remains blind to the activity, making persistence via UEFI bootkits significantly easier.

The affected shims are linked to multiple distributions and third-party tools, including Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, openSUSE, baramundi Management Suite up to 2024R1, WipeDrive versions 8.0.0 through 8.1.3, PC Doctor Service Center, and Abitti 1. Two CVEs—CVE-2026-8863 and CVE-2026-10797—cover different portions of the problem.

Mitigation Strategy

Microsoft has already published revocation entries for the vulnerable shims in the DBX database. Once applied, firmware will refuse to execute the old binaries even though they carry a valid signature. However, simply revoking the hashes without preparation can prevent systems from booting if older components remain in the chain.

The recommended sequence is therefore:

• First update shim, GRUB, and all other boot components to current versions that include SBAT (Shim Boot Application Table) protections.
• Only after these updates are verified, deploy the DBX revocations.
• Test the changes on a representative subset of machines before broad rollout.
• Inventory rescue media and maintenance USB drives, because any that still contain old shims will become unusable after revocation.

Administrators can verify the final state of Secure Boot variables using tools such as Check UEFISecureBootVariables on Windows or uefi dbx audit on Linux. It is also important to note that the scheduled expiration of the Microsoft UEFI CA 2011 certificate on 27 June 2026 does not automatically invalidate previously signed binaries; only an explicit DBX entry removes trust.

More information is available from The Hacker News, CERT Coordination Center (VU#616257), NIST NVD (CVE-2026-8863), and Help Net Security.