ESET finds 11 Microsoft-signed UEFI shims that bypass Secure Boot

By Ahmet Taş | Express Webdesign24

BERLIN, GERMANY — ESET researchers have uncovered 11 outdated Microsoft-signed UEFI shim bootloaders that attackers could use to bypass Secure Boot and execute unauthorised code before a computer’s operating system starts.

The affected shims are primarily version 0.9 or earlier and remained trusted because their Microsoft signatures had not previously been added to the UEFI Forbidden Signature Database, known as DBX. ESET reported the findings to the CERT Coordination Center in February 2026, and Microsoft revoked the identified binaries in its June 9 security update.

The issue does not mean that every device containing one of the associated products has been compromised. Exploitation generally requires administrative privileges or another ability to modify the system’s boot process. Once that access has been obtained, however, an attacker could introduce an old but still trusted shim and run malicious code before Windows, Linux or another operating system loads.

Eleven outdated bootloaders remained trusted

UEFI shim bootloaders are small, signed applications designed to connect a computer’s UEFI firmware to a second-stage bootloader, commonly GRUB 2 on Linux systems. They allow operating systems and third-party software to participate in Secure Boot without requiring every vendor’s signing key to be stored directly in the device firmware.

Over time, the open-source shim project received security corrections and new protection mechanisms. However, some vendors had already created customised versions based on much older source code and submitted those binaries to Microsoft for signing. Although the upstream weaknesses were later fixed, several previously signed versions remained trusted because they had not been explicitly revoked.

ESET found 11 such binaries connected to diagnostic utilities, management tools and older Linux distributions. CERT/CC’s affected-product list includes components associated with Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, OpenSUSE, PC-Doctor Service Center, WipeDrive and baramundi Management Suite, among others.

The findings are tracked principally under CVE-2026-8863 and CVE-2026-10797. ESET noted that the overall risk extends beyond two individual programming errors because old shims may also trust outdated second-stage bootloaders containing additional known vulnerabilities.

How Secure Boot protection can be bypassed

UEFI Secure Boot is intended to prevent untrusted software from running during startup. When the firmware attempts to load a boot application, it checks the file against two firmware-managed databases: the authorised-signature database, or DB, and the forbidden-signature database, or DBX.

A boot component must be signed by a trusted certificate or explicitly authorised hash in the DB. It must also not appear on the DBX revocation list. If both requirements are met, the firmware normally allows the application to execute.

The vulnerable shims were signed under the widely deployed Microsoft Corporation UEFI CA 2011 certificate. Because that certificate was trusted by many UEFI systems and the individual binaries had not been revoked, the firmware could treat them as legitimate even though their underlying code was outdated.

Attackers could use a method resembling the “Bring Your Own Vulnerable Driver” technique seen in operating-system attacks. Instead of exploiting a driver already installed on the victim’s device, the attacker brings a vulnerable but legitimately signed UEFI binary and places it in the boot chain.

The shim can then load an older trusted second-stage bootloader or exploit weaknesses in its own validation process. This may allow unsigned or otherwise blocked code to execute while Secure Boot still appears to be enabled.

Malicious code could run before security software starts

Code executed during the early boot phase operates before the main operating system and many endpoint-security controls have started. This gives boot-level malware an opportunity to interfere with the platform at a particularly sensitive stage.

CERT/CC warned that successful exploitation could allow an attacker to load unauthorised kernel components and establish persistent control over the device. Such malware may survive ordinary reboots and, in some circumstances, remain present even after the operating system has been reinstalled.

ESET said the vulnerable components could be used to facilitate malicious UEFI bootkits or other pre-boot malware. The research referenced known bootkit families such as BlackLotus, Bootkitty and HybridPetya to illustrate the type of threat that a Secure Boot bypass can enable.

This does not make the weakness a simple remote attack that can compromise any computer directly from the internet. CERT/CC states that an attacker would first require administrator-level privileges or another means of altering the boot process. The discovery is nevertheless important because an attacker who has gained that access could use the trusted shim to move beneath operating-system security controls.

Risk is not limited to users of the listed software

One of the most significant aspects of ESET’s findings is that a device does not need to have the affected product or Linux distribution installed.

An attacker can bring a separate copy of a vulnerable shim to another UEFI-based machine, provided the target trusts Microsoft’s third-party UEFI certificate and has not received the necessary DBX revocations. The technique therefore depends on the target’s Secure Boot trust configuration rather than only on its currently installed applications.

This means administrators should not interpret the affected-product list as a complete device inventory. The listed products identify where the vulnerable binaries originated, but the signed files can potentially be transferred to other systems.

ESET also explained that the expiration of an old signing certificate does not automatically prevent previously signed bootloaders from running. Secure Boot continues to trust a correctly signed binary while the certificate remains in the authorised database and the individual binary or certificate has not been added to DBX.

For permanent protection, vulnerable boot applications must therefore be explicitly revoked rather than merely allowed to age beyond the signing certificate’s validity period.

Microsoft revoked the binaries through the DBX update

ESET submitted its findings and proof-of-concept material to CERT/CC on February 16, 2026. Microsoft added the 11 identified Authenticode hashes to the DBX revocation update released with the June 9 Patch Tuesday security updates. ESET published its detailed technical analysis on July 14.

After the updated DBX has been successfully written to the device firmware, the affected bootloaders should no longer be accepted during Secure Boot verification. The firmware can recognise the revoked hashes and block the binaries before they execute.

Microsoft states that DBX updates are now distributed through normal monthly Windows servicing updates rather than requiring users to install a separate manual DBX package.

Updating Windows alone may not immediately complete every Secure Boot change. Some updates require a restart, and firmware compatibility problems can delay or block their installation. Microsoft provides Windows event-log entries that administrators can use to monitor successful DB, DBX and Secure Boot certificate updates or identify failures.

Windows and Linux systems should be checked

Windows users should install all available operating-system and security updates and restart the device when requested. Keeping Secure Boot enabled remains advisable; disabling it would remove an important defence rather than resolve the underlying revocation problem.

Business administrators should verify that the required DBX entries were applied successfully instead of relying only on the update status shown in the Windows interface. Microsoft documents specific TPM-WMI event IDs for successful Secure Boot changes, required restarts, firmware failures and blocked updates.

For Linux systems, ESET said the relevant updates should be distributed through the Linux Vendor Firmware Service. Administrators can also use the uefi-dbx-audit utility to inspect the revocation status of the system’s UEFI DBX database.

CERT/CC additionally recommends installing current firmware, bootloader and operating-system updates supplied by hardware and software vendors. Newer shim versions incorporate security fixes and modern revocation protections such as Secure Boot Advanced Targeting, or SBAT.

Organisations should test Secure Boot revocations before deploying them across large device fleets. Revoking an older component that is still required by a device, recovery medium or customised boot process could prevent that system from starting until compatible components are installed.

The discovery highlights a long-term trust-management problem

The immediate danger from the 11 reported shims has been reduced by Microsoft’s revocation update, but ESET said a broader visibility problem remains.

The shim-signing process became more transparent in 2017, when submissions began to be documented and publicly reviewed through the shim-review repository. Older Microsoft-signed binaries were not catalogued with the same consistency, making it difficult to determine how many outdated but still trusted shims may remain in circulation.

The case demonstrates that software signing is not a permanent guarantee of safety. A legitimately signed application may later become vulnerable, while the original signature continues to grant it trusted access unless an effective revocation process removes that trust.

For companies managing workstations, development machines or UEFI-based server environments, Secure Boot maintenance therefore requires more than confirming that the feature is switched on. Firmware updates, DBX revocations, current bootloaders and an accurate inventory of recovery and installation media all form part of the same security chain.

ExpressWebdesign24.de