Multiple vendor-signed UEFI applications have been confirmed vulnerable to Secure Boot bypass attacks leveraging a “Bring Your Own Vulnerable Driver” (BYOVD)-style exploitation technique, enabling attackers to execute arbitrary, unsigned code during the pre-boot phase, before the operating system or any endpoint security solution initializes.
CERT/CC published the coordinated disclosure on June 9, 2026, crediting ESET researcher Martin Smolar for identifying the affected binaries.
The vulnerabilities, tracked as CVE-2026-8863 and CVE-2026-10797, affect multiple vendor-signed UEFI applications, specifically, older versions of the open-source UEFI shim bootloader, that were signed under Microsoft’s “Microsoft Corporation UEFI CA 2011” third-party UEFI certificate.
The shim bootloader was originally designed as a bridge between a system’s UEFI firmware and Linux-based operating systems, allowing them to boot with Secure Boot enabled without requiring every distribution’s keys to be embedded in the motherboard’s NVRAM.
The root cause: many hardware and software vendors forked or customized older versions of the shim project for their own products but never updated those binaries when upstream security vulnerabilities were patched.
These outdated, signed binaries remained trusted by Secure Boot, and were never revoked through Microsoft’s DBX revocation list, creating a silent, long-term supply chain exposure.
The attack model is straightforward: because these binaries are cryptographically signed, an attacker does not need to compromise a vendor’s update server.
They simply need to bring their own copy of a vulnerable signed binary and present it to any Secure Boot-enabled system that trusts the Microsoft UEFI CA 2011 certificate.
| CVE ID | Severity | Attack Vector | Affected Component | Researcher |
|---|---|---|---|---|
| CVE-2026-8863 | Critical | Local / Physical | UEFI shim ≤ 0.9 (multiple vendors) | Martin Smolar, ESET |
| CVE-2026-10797 | High | Local / Physical | UEFI shim 0.9 (Red Hat, CentOS, Oracle Linux 7.2) | Martin Smolar, ESET |
Both CVEs were publicly disclosed on June 9, 2026, following coordinated notification of 38 vendors beginning as early as February 16, 2026.
ESET researchers identified a broad list of affected vendor-signed UEFI applications. The impacted vendor-signed UEFI shim bootloaders include binaries from Acer, AMD, ASUS (schenker-tech.de/XMG), ECS, Getac, GIGABYTE (Maibenben), Toshiba, Uniwill (Maingear/XMG).
As well as software vendors including Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, baramundi Management Suite (up to 2024R1), WhiteCanyon/Blancco WipeDrive (versions 8.0.0–8.1.3), Spyrus WTGCreator, PC-Doctor Service Center (versions 15 and 16), OpenSUSE shim loader (0.9), and Finland’s Matriculation Examination Board (Abitti 1.0).
GIGABYTE confirmed in its security advisory that while its BIOS implementations do not bundle the vulnerable shim binaries, systems that trust the Microsoft UEFI CA 2011 certificate remain susceptible if an attacker introduces a vulnerable shim via an external source, such as a USB boot device.
The vulnerable functions exposed across many of these applications include mm, dmpstore, and setvar, UEFI shell commands that allow direct manipulation of system memory and NVRAM variables, enabling bypass of Secure Boot policy enforcement.
In a traditional BYOVD attack, threat actors use a legitimately signed but vulnerable kernel driver to achieve elevated privileges or disable security tools. The UEFI variant follows the same logic but operates at an even deeper layer, the pre-OS firmware environment.
An attacker with administrative privileges or physical access to a target system:
- Drops a vulnerable, vendor-signed shim binary onto the target system
- Configures the UEFI boot order to execute the vulnerable binary
- Uses exposed UEFI shell commands (e.g.,
mm,setvar) to manipulate NVRAM variables and disable Secure Boot enforcement - Executes arbitrary or unsigned code, including UEFI bootkits like Bootkitty or BlackLotus, during the early boot phase
This technique is particularly dangerous because execution happens before the OS kernel, before endpoint detection and response (EDR) platforms, and before any antivirus solution initializes.
Malicious implants installed this way can survive OS reinstallations and disk wipes, achieving the highest level of persistence on a compromised system.
The UEFI Forbidden Signature Database (DBX) is the revocation list that prevents specific signed binaries from executing during the Secure Boot process.
Microsoft will distribute updated DBX entries revoking the trust of all affected shim binaries through its June 2026 Patch Tuesday update cycle.
GIGABYTE and other affected vendors recommend the following update order to prevent rendering systems unbootable:
- First, apply OS updates that include new trusted boot application certificates (DB update)
- Then, apply the DBX revocation update to block the vulnerable binaries
Reversing this order, applying DBX revocations before updated trusted boot components are in place, can cause systems to reject newly updated, legitimate boot components. Enterprises managing large-scale deployments should test DBX updates in staging environments before broad rollout.
For Linux systems, DBX updates are available through the Linux Vendor Firmware Service (LVFS) via fwupdmgr. Audit tools such as Check-UEFISecureBootVariables (Windows/PowerShell) and uefi-dbx-audit (Linux) can verify whether the latest DBX has been applied and identify any revoked or vulnerable boot components still present on a system.
This disclosure echoes CVE-2024-7344, a prior ESET-discovered vulnerability patched in January 2025, where a custom PE loader in UEFI recovery applications bypassed the standard LoadImage and StartImage secure functions.
The pattern is consistent: vendors sign UEFI components, fork upstream projects, and then fail to apply upstream security patches, leaving signed-but-vulnerable binaries in the wild for years.
In July 2024, Microsoft released the DBX2024 update for CVE-2024-28924, but it was not included in the UEFI Forum’s official DBX, meaning non-Microsoft ecosystems relying on LVFS remained exposed for nearly six months.
These recurring gaps underscore the need for faster cross-ecosystem coordination between Microsoft, the UEFI Forum, firmware vendors, and Linux distribution maintainers.
- Apply June 2026 Patch Tuesday updates immediately; Microsoft’s DBX revocation will be distributed through standard OS update channels
- Update BIOS/UEFI firmware from your hardware vendor’s official website for the latest DBX-integrated firmware releases
- Run DBX audit tools (
Check-UEFISecureBootVariableson Windows,uefi-dbx-auditon Linux) to confirm revocation status - Keep Secure Boot enabled at all times and restrict UEFI boot order modifications via firmware password policies
- Restrict administrative and physical access to prevent attackers from introducing vulnerable binaries via external boot media
- For Linux environments, update shim bootloaders to versions incorporating SBAT (Secure Boot Advanced Targeting) protections via your distribution’s package manager
FAQ
Q1: Does this vulnerability affect systems without Secure Boot enabled?
No — systems with Secure Boot disabled are already not using boot-time signature enforcement, so the bypass is irrelevant, but they face broader pre-OS security risks.
Q2: Can endpoint security tools detect exploitation of CVE-2026-8863?
No — because the malicious code executes in the pre-OS boot phase, before EDR and antivirus solutions initialize, making detection by standard security controls effectively impossible.
Q3: Is physical access always required to exploit these vulnerabilities?
No — an attacker with local administrative privileges on a running OS can also stage the attack without requiring direct physical access to the hardware.
Q4: Will updating Windows alone fully remediate this vulnerability?
Partially — Windows/OS updates distribute the DBX revocation, but full remediation also requires a BIOS/UEFI firmware update from your hardware vendor to embed the latest DBX into firmware.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
