Do Son 
TL;DR
CERT/CC disclosed a Secure Boot bypass that affects many vendor-signed UEFI applications. ESET researcher Martin Smolar discovered the flaws. An attacker can run unverified code before the operating system loads. Vendors are now revoking the affected binaries through UEFI DBX updates. The advisory landed on June 18, 2026.
Why It Matters
Secure Boot exists to block untrusted code at startup. This Secure Boot bypass breaks that core promise. Major OEMs signed the vulnerable binaries, so firmware trusts them by default. As a result, an attacker gains a foothold in the earliest boot stage. That foothold sits below the operating system and most defenses.
The payoff for an attacker is severe. According to CERT/CC, code at this stage can “achieve persistent platform compromise.” Such code can survive reboots and even full OS reinstalls. Worse, it runs before security products start. The advisory warns that malicious code “may completely evade detection by standard security controls.” Endpoint detection tools therefore offer little help here.
How the Attack Works
The method mirrors a “Bring Your Own Vulnerable Driver” (BYOVD) attack. However, the attacker abuses a signed UEFI application instead of a driver. The flaws affect several UEFI shell builds and a GRUB2 module. These tools expose powerful functions, including memory writes (mm), variable edits (setvar), and dmpstore. Each affected binary still carries a valid vendor signature. Strict access controls are missing. Therefore, an attacker can use these functions to load unsigned code. That step defeats the Secure Boot policy during the pre-boot phase. Trust flows from the Authorized Signature Database, which stores the OEM certificates.
Exploitation Status
No public proof-of-concept exploit has surfaced for these specific binaries. Researchers have reported no in-the-wild abuse either. Notably, the attack needs administrative privileges or physical access to plant the files.
Affected Vendors
The list spans many hardware makers. Affected names include Acer, AMD, ASUS, ECS, Getac, GIGABYTE, Toshiba, and Maingear-branded Uniwill systems. Many entries are different UEFI shell binaries from the same vendors. AMD declined to issue a CVE, citing end-of-support status for the affected product. As a result, no single CVE tracks the whole issue, and CERT/CC uses the identifier VU#457458 instead.
Patch and Mitigation
Start by applying firmware and software updates from your hardware vendor. These packages replace the vulnerable applications with corrected versions. Next, update the UEFI DBX so the bad binaries can no longer run. You can review the full vendor list and file hashes in the CERT/CC advisory VU#457458. Finally, administrators should verify that the revocations took effect on each machine.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
