Eleven Old Microsoft-Signed UEFI Shims Can Bypass Secure Boot

Eleven outdated UEFI shim bootloaders signed by Microsoft could allow attackers to bypass Secure Boot and execute untrusted code before the operating system starts. The affected binaries primarily use shim version 0.9 or earlier and remained trusted because their signatures had not been added to the UEFI forbidden-signature database.

The issue affects unpatched systems that trust the Microsoft Corporation UEFI CA 2011 certificate for third-party boot software. It is not limited to computers running the Linux distributions or utilities that originally shipped the vulnerable files. An attacker with administrative privileges or another way to modify the boot process can supply a vulnerable shim directly.

ESET Research reported the shims to CERT/CC in February 2026. Microsoft revoked their Authenticode hashes through a dbx update released with the June 9, 2026 security updates.

Who Is Affected by the UEFI Shim Secure Boot Bypass?

A system is exposed when Secure Boot is enabled, the firmware trusts Microsoft’s third-party UEFI certificate, and the latest dbx revocations have not been applied.

The installed operating system does not determine exposure. The same vulnerable shim can be brought to a Windows or Linux device if its firmware accepts the Microsoft signature and does not contain the new hash-based revocation.

Windows 11 Secured-core PCs should disable trust in Microsoft’s third-party UEFI certificate by default. Administrators should still verify the actual firmware configuration because device vendors and enterprise policies can change default settings.

Condition	Required for this attack path?
UEFI-based system	Yes
Secure Boot enabled	Yes, because the technique targets Secure Boot validation
Microsoft third-party UEFI certificate trusted	Yes
June 2026 dbx revocations missing	Yes
Affected Linux distribution installed	No
Attacker can modify the boot process or EFI System Partition	Yes

What Is a Linux UEFI Shim?

A shim is a small first-stage bootloader that helps Linux distributions work with UEFI Secure Boot. Microsoft signs the shim, allowing firmware that trusts Microsoft’s third-party certificate to load it.

The shim then creates another trust layer for distribution-specific components. It usually verifies GRUB 2 using a certificate embedded by the Linux vendor, while GRUB verifies the operating-system kernel before transferring control.

This design avoids requiring every hardware manufacturer to include certificates for every Linux distribution in firmware. It also means that one trusted shim can approve numerous second-stage bootloaders and utilities.

How the Secure Boot Bypass Works

The attacker places an old Microsoft-signed shim on the EFI System Partition together with a compatible second-stage bootloader, often a vulnerable version of GRUB 2. The firmware accepts the shim because its Microsoft signature remains trusted.

The old shim then validates the second-stage component using an embedded vendor certificate. Because early shim versions lack newer revocation protections, they may load boot components that a modern shim would reject.

The attacker can exploit a weakness in the trusted second-stage bootloader to execute unsigned code. This can provide control before the operating system and many endpoint-security products begin running.

1. The attacker gains administrative privileges or another way to modify the boot files.
2. The attacker copies a vulnerable Microsoft-signed shim to the EFI System Partition.
3. A compatible and vulnerable second-stage bootloader is added.
4. UEFI firmware accepts the shim because the signature is trusted and its hash is absent from dbx.
5. The shim loads the second-stage component without enforcing newer revocation policies.
6. The attacker uses the second-stage weakness to run untrusted pre-boot code.

The Technique Resembles Bring Your Own Vulnerable Driver

CERT/CC compares the method to a Bring Your Own Vulnerable Driver attack. Instead of relying on a bootloader already installed on the victim’s system, the attacker supplies a legitimately signed but vulnerable component.

The CERT/CC vulnerability note VU#616257 states that exploitation can allow arbitrary code to run during the early boot phase. The code may load unsigned kernel components and create persistence that survives reboots and, in some cases, operating-system reinstallation.

This is not a remote attack by itself. The attacker must first obtain sufficient access to change the boot environment or otherwise control what the firmware loads.

Old Shims Ignore Modern Revocation Protections

The affected shims predate several protections added to the upstream shim project. Machine Owner Key revocation through MokListX began receiving enforcement in shim version 0.9, while Secure Boot Advanced Targeting arrived in version 15.3.

Shims older than these protections do not understand the newer policies. An attacker can therefore replace a current shim with an older signed version that ignores revocations intended to block compromised keys or vulnerable bootloader generations.

The weakness becomes more serious because one shim may trust many vendor-signed files. ESET found that the number ranged from fewer than 10 components in specialized software to nearly 100 in major Linux distributions.

Protection	Purpose	Why old shims are vulnerable
MokListX	Rejects revoked Machine Owner Keys	Shims before enforcement support may ignore the denylist
SBAT	Blocks vulnerable generations of boot components	Pre-15.3 shims do not evaluate SBAT policy
UEFI dbx	Blocks forbidden certificates and binary hashes	The 11 shim hashes remained absent until the June 2026 update

Two CVEs Track the UEFI Shim Problems

Two CVE identifiers cover the disclosed shim issues. They describe related but distinct parts of the broader Secure Boot bypass risk.

CVE	Scope
CVE-2026-8863	Multiple Microsoft-signed shims that can be used to bypass Secure Boot because they lack or fail to enforce modern protections
CVE-2026-10797	A certificate-revocation bypass caused by inconsistent handling of PE signature-size fields

CVE-2026-8863 covers the main group of old, trusted shims and the Secure Boot bypass conditions documented through the coordinated disclosure.

CVE-2026-10797 tracks a flaw that upstream shim developers fixed nearly a decade earlier. The old Microsoft-signed binaries containing that code were never revoked until this investigation.

CVE-2026-10797 Bypasses Certificate Revocation Checks

An Authenticode-signed PE file records the signature length in two places: the PE header’s security-data directory and the WIN_CERTIFICATE structure.

In the affected shims, the revocation-check function and signature-verification function used different size values. An attacker could modify the second-stage bootloader’s certificate structure so the revocation check examined the wrong data.

The flaw can bypass certificate-based revocations in dbx or MokListX. It does not bypass hash-based revocation, and the second-stage bootloader must use a certificate embedded in the vulnerable shim.

Eleven UEFI Shims Were Added to the Forbidden List

The affected files came from Linux distributions, diagnostic software, secure-erasure products, management tools, and other UEFI applications. This shows that shim security extends beyond mainstream Linux installation media.

The updated CERT/CC advisory identifies the following products and shim versions.

Vendor or project	Product	Reported shim version
Spyrus	WTGCreator 4.2	0.7 or earlier
Red Hat	Red Hat Enterprise Linux 7.2	0.9
CentOS	CentOS 7.2	0.9
baramundi software	baramundi Management Suite through 2024 R1	0.8
WhiteCanyon and Blancco	WipeDrive 8.0.0 through 8.1.3	0.7
Finland’s Matriculation Examination Board	Abitti 1	0.8
NTC IT ROSA	ROSA Linux R9 and R10	0.9
Oracle	Oracle Linux 7.2	0.9
PC-Doctor	PC-Doctor Service Center 15 and 16	0.9
openSUSE	openSUSE UEFI shim loader	0.9
openSUSE	openSUSE Shim 2.1	0.9

A Vulnerable Oracle Linux Chain Shows the Practical Risk

ESET demonstrated the attack using an old Oracle Linux shim and a GRUB 2 binary from Oracle Linux 7.1 installation media. The GRUB binary was vulnerable to CVE-2015-5281.

That GRUB flaw allows unsigned code to load through the multiboot or multiboot2 commands. The attacker can build a custom unsigned kernel image, place it beside the shim and GRUB files, and execute it during startup.

The attack does not require a memory-corruption exploit, return-oriented programming chain, or forged Microsoft signature. It relies on old components that the firmware and shim still consider trustworthy.

Secure Boot Bypass Can Enable UEFI Bootkits

Code running before the operating system can interfere with the kernel, security controls, and the boot chain. It may also establish persistence below the level normally inspected by endpoint detection tools.

Researchers warn that the bypass could support bootkits such as Bootkitty, HybridPetya, or BlackLotus. Their inclusion illustrates the type of malware the bypass could enable and does not establish that attackers have used these 11 shims to deploy those bootkits in the wild.

Neither ESET nor CERT/CC reported confirmed malicious exploitation of these specific 11 binaries. Their presence on a system is also not proof of compromise because they were distributed as legitimate software.

Microsoft Revoked the Shims in June 2026

Microsoft added the 11 PE Authenticode hashes to the UEFI Forbidden Signature Database, known as dbx, through its June 9, 2026 security release.

The Microsoft June 2026 security release distributes the relevant Secure Boot revocations for supported Windows systems. Once the firmware contains those hashes in dbx, it should reject the vulnerable shims even though Microsoft originally signed them.

The patch revokes the specific identified binaries. It does not automatically identify every forgotten Microsoft-signed shim created before the current public review process.

Certificate Expiration Does Not Remove Secure Boot Trust

The Microsoft Corporation UEFI CA 2011 certificate expired on June 27, 2026. That expiration does not cause UEFI firmware to reject every binary previously signed with the certificate.

Secure Boot continues trusting a correctly signed binary while its signing certificate remains in the authorized database and the binary or certificate is not present in dbx.

This makes explicit revocation essential. Waiting for the signing certificate to expire does not protect systems from old signed boot components.

How Windows and Linux Administrators Should Respond

Administrators should test UEFI revocation updates on representative hardware before broad deployment. Firmware and boot configurations vary, and a revocation can cause startup failures when a system still depends on a blocked bootloader.

For this disclosure, the required protection is the latest dbx update containing the 11 revoked hashes. Organizations should follow their operating-system and device vendors’ instructions instead of manually changing Secure Boot databases without a tested recovery plan.

1. Install current operating-system and Secure Boot security updates.
2. Confirm that the June 2026 or later dbx data reached the device firmware.
3. Update legitimate bootloaders and recovery media before enforcing revocations.
4. Test updates on non-critical systems using the same hardware and boot configuration.
5. Keep recovery keys, approved boot media, and rollback procedures available.
6. Inspect the EFI System Partition for unauthorized boot entries and unfamiliar files.
7. Restrict administrative access and monitor changes to EFI boot variables.
8. Review dual-boot, recovery, diagnostic, and disk-erasure tools for old shims.

Windows administrators can use elevated PowerShell commands to read the firmware’s dbx variable and compare it with the 11 revoked Authenticode hashes. The Microsoft Security Update Guide should be used to confirm applicable updates for supported Windows releases.

Linux administrators should obtain the latest UEFI revocation updates through their distribution or the Linux Vendor Firmware Service. They can use the uefi-dbx-audit project to examine whether the required revocations are installed.

Why Applying dbx Updates Requires Care

A dbx update is designed to make a previously trusted bootloader unbootable. If a computer, recovery disk, installation image, or diagnostic tool still relies on one of the revoked files, the firmware may refuse to start it after the update.

Organizations should update legitimate boot media first and verify that current replacements boot successfully. They should also test operating-system recovery, full-disk encryption recovery, network booting, and hardware-diagnostic workflows.

Broader Microsoft Secure Boot certificate transitions may include separate sequencing requirements for new authorized certificates and later revocations. Administrators should not apply those instructions to unrelated dbx changes without checking the vendor’s documentation for the exact update.

Pre-2017 Shim Visibility Remains Incomplete

The public shim-review process began improving transparency in 2017 by recording vendor submissions before Microsoft signed them. Older submissions do not have the same complete public inventory.

As a result, researchers cannot say with certainty how many pre-2017 Microsoft-signed shims remain trusted and unrevoked. Additional obsolete binaries may exist outside the 11 files addressed in June.

ESET’s shim investigation concludes that revoking these binaries resolves the immediate findings but not the wider visibility problem. Defenders need accurate inventories, current dbx data, monitored EFI partitions, and stronger controls over boot-chain changes.

FAQ