A critical firmware-level attack vector that affects multiple vendor-signed UEFI applications, enabling attackers to bypass Secure Boot protections and execute arbitrary Code before the operating system loads.
Discovered by Martin Smolar of ESET, the vulnerability mirrors a “Bring Your Own Vulnerable Driver” (BYOVD) approach but targets the pre-boot environment rather than the OS kernel.
The Unified Extensible Firmware Interface (UEFI) standard governs how modern hardware initializes and hands off control to the operating system. When Secure Boot is enabled, every UEFI application or driver must carry a cryptographically verified signature before execution.
Trusted UEFI Certificates Exploited
Trust is managed through firmware databases, most critically the Authorized Signature Database (DB), which stores certificates from OEM vendors, OS authorities, and supply-chain partners.
Certain vendor-signed UEFI applications, including UEFI shells and bootloaders, expose sensitive functions such as direct memory manipulation (mm), NVRAM variable modification (setvar, dmpstore), and raw driver loading without adequate access controls.
If a target system’s DB trusts the vendor’s certificate, an attacker with administrative privileges or physical access can weaponize these applications to load unverified, malicious Code during the early boot phase, entirely bypassing Secure Boot policy enforcement.
The vulnerability spans hardware from over a dozen major manufacturers. Affected applications include UEFI shells and GRUB2 instances signed by Acer, AMD, ASUS, ECS, Getac, GIGABYTE, Toshiba, and others, including Emdoor, Maibenben, Uniwill, Maingear, and XMG (schenker-tech.de). Below are select affected binaries:
| Vendor | Application | Vulnerable Function | SHA1 (Authenticode) |
|---|---|---|---|
| Acer | GRUB2 | insmod | 71DCE405964C67779DB92DBC01F683D6E29075AB |
| Acer | UEFI Shell | mm, dmpstore | D275C2DFD884D2B7842C7F861C527A9FFC6E59DD |
| AMD | UEFI Shell | mm, dmpstore | 744565FBB35DB710BCC1547292204763C731DC55 |
| ASUS / XMG | UEFI Shell | mm, dmpstore | DC18D31E46A541C9E42F9588554ADDC7DECE124B |
| Getac | UEFI Shell | mm, dmpstore | 35FBD8ED5ED31D281A6146360CDEFE7E8CEC31DA |
| Toshiba | UEFI Shell | mm, dmpstore | 2EAE2807A4265D9C30EECA68A8C59C7A6D1ACFE7 |
Code executed at the pre-boot stage runs before the operating system and any endpoint security products initialize. This means malicious payloads deployed through this technique can completely evade detection by EDR solutions and antivirus tools.
More critically, a successful exploit can achieve persistent platform compromise by loading unsigned or malicious kernel components that survive both system reboots and full OS reinstallations, Martin Smolar said.
Mitigation
Administrators should take the following steps immediately:
- Apply vendor firmware updates that replace vulnerable UEFI applications with patched versions incorporating upstream security fixes.
- Update the UEFI Forbidden Signature Database (DBX) on all affected systems to revoke trust in the identified vulnerable binaries, preventing them from executing during boot.
- Verify DBX integrity post-update by referencing guidance published by CISA and the NSA on UEFI Secure Boot hardening.
- Restrict physical and administrative access to systems, as exploitation requires either physical presence or elevated OS-level privileges.
The affected binaries are being added to vendor-specific DBX revocation lists. Organizations relying on hardware from the listed vendors should treat this as a high-priority firmware security update and cross-reference their inventory against the published SHA-256 hash values to assess exposure.
Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google.
