Mastodon Mastodon Mastodon Mastodon

ESET finds vulnerable legacy UEFI shims undermining Secure Boot

Photo of author

CyberSecureFox Editorial Team

Published:

Researchers at ESET identified 11 legacy UEFI bootloaders (so-called shims) signed by Microsoft that are still considered trusted on most UEFI systems and can be used to bypass Secure Boot. The vulnerability affects any device that trusts the Microsoft Corporation UEFI CA 2011 certificate, regardless of the installed operating system. An attacker with administrative privileges or access to the boot process can replace a current bootloader with a legacy one, execute arbitrary code before the OS is initialized, and deploy a UEFI bootkit that is invisible to security tools. Microsoft revoked the vulnerable bootloaders as part of the June 2026 Patch Tuesday update. The issues are tracked as CVE-2026-8863 and CVE-2026-10797.

Vulnerability mechanism: why old bootloaders are dangerous

Shim is a lightweight, open-source bootloader that acts as an intermediary between the motherboard firmware and the operating system. Its main task is to enable booting Linux distributions when Secure Boot is enabled. The trust chain looks like this: the UEFI firmware verifies shim’s signature against the Microsoft CA certificate stored in the firmware; shim validates the second-stage bootloader (usually GRUB 2) using the vendor certificate embedded in shim; GRUB 2 then verifies the kernel using the same certificate.

According to ESET, the problem is not a new vulnerability but the fact that outdated shim versions (mainly 0.9 and below) remained signed and trusted despite long-standing flaws that had already been fixed in the upstream project. As CERT/CC noted, vendors did not update their bootloaders after the patches were released, and Microsoft did not add them to the DBX revocation list. This created a long-term supply-chain weakness: outdated boot components continued to run on fully patched systems.

The attack follows the BYOVD (Bring Your Own Vulnerable Driver) pattern: the attacker brings along a copy of an old but still trusted shim binary. This alone is enough to bypass both the Machine Owner Key (MOK) mechanism and Secure Boot Advanced Targeting (SBAT), systems designed to revoke vulnerable boot components.

Affected products

According to the researchers, vulnerable shim bootloaders were used in the following products:

  • Spyrus WTGCreator — shim version 0.7 and below
  • Red Hat Enterprise Linux 7.2 — shim version 0.9
  • Red Hat CentOS 7.2 — shim version 0.9
  • baramundi Management Suite (up to 2024R1) — shim version 0.8
  • WhiteCanyon/Blancco WipeDrive (8.0.0–8.1.3) — shim version 0.7
  • Abitti 1 (Finnish Matriculation Examination Board, version 1.0) — shim version 0.8
  • ROSA Linux (R10, R9) — shim version 0.9
  • Oracle Linux 7.2 — shim version 0.9
  • PC-Doctor Service Center (15, 16) — shim version 0.9
  • OpenSUSE UEFI Shim loader — shim version 0.9
  • OpenSUSE Shim 2.1 — shim version 0.9

Note: the list of affected products is based on ESET’s data and is not confirmed by individual vendor advisories in available sources.

Technical details of the CVEs

CVE-2026-8863 is related to the possibility of using outdated but not revoked shim bootloaders to bypass Secure Boot. CVE-2026-10797 refers to a previously fixed issue in shim that allowed bypassing the certificate revocation mechanism by modifying the signature header of the second-stage bootloader. CVSS scores are not specified in available sources. Neither vulnerability has been added to the CISA KEV catalog, and there are currently no confirmed cases of exploitation in real-world attacks.

ESET emphasizes that the expiration of the Microsoft Corporation UEFI CA 2011 certificate (June 27, 2026, according to Microsoft documentation) by itself does not affect Secure Boot verification. Bootloaders signed with an expired certificate continue to be treated as trusted until they are explicitly revoked by hash.

Impact assessment

The threat affects a wide range of systems — from enterprise servers running Red Hat and Oracle Linux to specialized solutions such as remote data wiping systems (WipeDrive) and exam platforms (Abitti). Since the code executes before the operating system and security tools are initialized, malicious bootloaders can evade detection by EDR solutions and built-in OS security mechanisms. According to the researchers, compromise at the bootloader level provides persistence that survives reboots and, in some cases, even OS reinstallation.

ESET separately stresses the low barrier to entry for attackers: no complex exploits are required — a copy of an old, trusted but not revoked shim binary and a basic understanding of how UEFI bootloaders work are sufficient.

Recommendations

  • Install the June 2026 Patch Tuesday update, which includes revocation of vulnerable shim bootloaders via an update to the DBX list.
  • Check the shim version on Linux systems with Secure Boot enabled. Versions 0.9 and below require immediate updating.
  • Ensure the UEFI DBX revocation list is up to date. On systems that do not receive Windows updates automatically (Linux servers, specialized devices), updating DBX may require manual intervention.
  • Audit boot partitions for legacy shim binaries, especially on systems using the affected products listed above.
  • Restrict physical access and administrative privileges on critical systems, since exploitation requires the ability to modify the boot process.
  • Organizations using baramundi Management Suite, WipeDrive, or PC-Doctor should contact their vendors to obtain updated versions with current shim bootloaders.

This case illustrates a systemic issue in the Secure Boot ecosystem: a trust model based on signatures only works if compromised components are revoked in a timely manner. Organizations running Linux systems with Secure Boot must first ensure that the June 2026 DBX update has been applied to all devices, including those not managed via Windows Update — these are the ones that remain most exposed to attacks leveraging legacy bootloaders.


CyberSecureFox Editorial Team

The CyberSecureFox Editorial Team covers cybersecurity news, vulnerabilities, malware campaigns, ransomware activity, AI security, cloud security, and vendor security advisories. Articles are prepared using official advisories, CVE/NVD data, CISA alerts, vendor publications, and public research reports. Content is reviewed before publication and updated when new information becomes available.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.