{"vuid":"VU#457458","idnumber":"457458","name":"Vendor-signed UEFI applications found vulnerable to Secure Boot bypass","keywords":null,"overview":"### Overview\r\nMultiple vendor-signed UEFI applications are vulnerable to Secure Boot bypass via a \"Bring Your Own Vulnerable Driver\" (BYOVD)-style attack. If a target system trusts the affected vendor’s certificate, an attacker can exploit these applications to execute arbitrary code during the early pre-boot phase before the operating system initializes. To mitigate this risk, system administrators should apply updates to the UEFI Forbidden Signature Database (DBX) that revoke trust in the affected vendor-signed binaries, preventing these vulnerable applications from executing during the boot process.\r\n\r\n\r\n### Description\r\nThe Unified Extensible Firmware Interface ([UEFI](https://uefi.org)) standard defines the modern firmware architecture used to initialize hardware and transfer control to the operating system during system startup. On systems with Secure Boot enabled, UEFI applications and drivers must be cryptographically signed and verified before execution. Trust for these signatures is established through several firmware-managed databases, including the authorized signature database (DB), which commonly contains certificates from original equipment manufacturer (OEM) vendors, operating system authorities, and other supply-chain partners in the UEFI ecosystem. \r\n\r\nThe `UEFI shell` is a command-line application that allows advanced users to interact directly with the UEFI environment to run diagnostics or special tasks prior to the operating system boot. Other UEFI applications, such as bootloaders, manage the operating system startup sequence or load specific drivers before the main OS initializes. Some of these applications possess functionalities that can manipulate system memory, modify sensitive NVRAM variables, or load raw drivers. \r\n\r\nIf a vendor-signed application inadvertently exposes these capabilities without strict access controls, attackers can abuse them to circumvent Secure Boot policies and execute unverified code. This exposure effectively results in an early compromise of the pre-boot environment, bypassing the Secure Boot policy.\r\n\r\nResearchers from ESET identified multiple UEFI applications vulnerable to this type of abuse. To neutralize the risk, the affected binaries will be added to vendor-specific DBX revocation lists to prevent them from executing on the target systems.\r\n\r\n\t\r\n \r\n \r\n \r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\t
Impacted UEFI Applications
\r\n\t\t[Vendor, Application and vulnerable function
\r\n\t\tAuthenticode SHA hash
\r\n\t\tSHA256 file hash]
\r\n\t\t
Acer `GRUB2` insmod\r\n71DCE405964C67779DB92DBC01F683D6E29075AB\r\n6cc0e9501420ec036f0ad74df2d17f4d6360f26585f265042537b9f8c2780c30
Acer `UEFI shell` mm,dmpstore\r\nD275C2DFD884D2B7842C7F861C527A9FFC6E59DD\r\nb0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
Acer `UEFI shell` mm,dmpstore\r\n42C4923E676A9FD0A93C08631AD7A8244A8F2174\r\n0784c30a83bfcc45bf42804e5729323987957f0a104fcb693d0ff10d76d5b42c
Acer `UEFI shell` mm,dmpstore\r\n04BE47C873F116B85111FBF8EE9191C87CEE2619\r\nb0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
Acer Emdoor `UEFI shell` mm,setvar\r\nCD5E3EAD6F78526BF9301DEEF66906618654F604\r\n14a493007443c72050ce644562db1470e36bf9d04baf5dec6b046e32cbdbb61b
AMD `UEFI shell` mm,dmpstore\r\n744565FBB35DB710BCC1547292204763C731DC55\r\n58bc1e460a1b7e18e6ad12dae8020c38bd7b3d6217130dd127ae232e4b248406
ASUS schenker-tech.de(XMG) `UEFI shell` mm,dmpstore\r\nDC18D31E46A541C9E42F9588554ADDC7DECE124B\r\n61ee9a23c366a102ceb34c78af7816413769791658cdb668b02cb81ec94f7c70
ECS `UEFI Shell` mm,dmpstore\r\n59BA2B5C239AF3CC7FCE74AA5E65AAA8CE3C454F\r\n81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d66908
Getac `UEFI Shell` mm,dmpstore\r\n35FBD8ED5ED31D281A6146360CDEFE7E8CEC31DA\r\n09d895bb03bdac3188ef61b09ab72b99492cfd0b785cbc3eb2eb75657a2f9fa0
GIGABYTE Maibenben `UEFI Shell` mm,setvar,dmpstore\r\n6CC172CBFEEA24B2806B477F8EDF897334ECC486\r\n2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416
Toshiba `UEFI Shell` mm,dmpstore\r\n2EAE2807A4265D9C30EECA68A8C59C7A6D1ACFE7\r\ncad246ae8a5db51f32f128896ccef5efc30e5d65c9d9722b449988d43da53d51
Uniwill Maingear schenker-tech.de(XMG) `UEFI Shell` mm,dmpstore\r\n8CED62F9BD5C987A80598DA1E13414391BBB1ADE\r\n55682bec887134a2ccaa2cd5458cd3fe6395ea93bb88c9dc541806428b14fc66
\r\n\r\n### Impact\r\nThis vulnerability only impacts systems where the specific affected vendor's certificate is trusted within the UEFI Authorized Signature Database (DB). On such systems, an attacker with administrative privileges or physical access could leverage the vulnerable application to bypass Secure Boot protections and execute arbitrary code before the operating system loads. \r\n\r\nCode executed during this early boot phase can achieve persistent platform compromise, including the ability to load unsigned or malicious kernel components that survive system reboots and operating system reinstallations. Because this activity occurs before the operating system and endpoint security products initialize, malicious code executed through this technique may completely evade detection by standard security controls and endpoint detection and response (EDR) solutions.\r\n\r\n### Solution\r\nApply the latest firmware and software updates provided by your hardware or software vendor. Please refer to the Vendor Information section for details. Updated software packages will replace vulnerable UEFI applications with corrected versions that incorporate the latest upstream security fixes.Additionally, administrators should update and verify the [UEFI DBX](https://media.defense.gov/2025/Dec/11/2003841096/-1/-1/0/CSI_UEFI_SECURE_BOOT.PDF) on affected systems to ensure the vulnerable binaries are revoked and can no longer execute during the boot process.\r\n\r\n### Acknowledgements\r\nThanks to Martin Smolar of ESET for researching and reporting this vulnerability. This document was written by Vijay Sarvepalli.","clean_desc":null,"impact":null,"resolution":null,"workarounds":null,"sysaffected":null,"thanks":null,"author":null,"public":["https://uefi.org/specs/UEFI/2.11/32_Secure_Boot_and_Driver_Signing.html","https://uefi.org/specs/UEFI/2.11/03_Boot_Manager.html","https://uefi.org/specs/UEFI/2.11/07_Services_Boot_Services.html","https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot","https://www.welivesecurity.com/en/eset-research/under-cloak-uefi-secure-boot-introducing-cve-2024-7344/","https://www.eset.com/us/about/newsroom/press-releases/eset-research-discovers-uefi-secure-boot-bypass-vulnerability/","https://github.com/sei-vsarvepalli/uefi-dbx-audit/"],"cveids":[],"certadvisory":null,"uscerttechnicalalert":null,"datecreated":"2026-06-18T19:41:08.413120Z","publicdate":"2026-06-18T19:41:08.033874Z","datefirstpublished":"2026-06-18T19:41:08.432282Z","dateupdated":"2026-06-18T19:41:08.033870Z","revision":1,"vrda_d1_directreport":null,"vrda_d1_population":null,"vrda_d1_impact":null,"cam_widelyknown":null,"cam_exploitation":null,"cam_internetinfrastructure":null,"cam_population":null,"cam_impact":null,"cam_easeofexploitation":null,"cam_attackeraccessrequired":null,"cam_scorecurrent":null,"cam_scorecurrentwidelyknown":null,"cam_scorecurrentwidelyknownexploited":null,"ipprotocol":null,"cvss_accessvector":null,"cvss_accesscomplexity":null,"cvss_authentication":null,"cvss_confidentialityimpact":null,"cvss_integrityimpact":null,"cvss_availabilityimpact":null,"cvss_exploitablity":null,"cvss_remediationlevel":null,"cvss_reportconfidence":null,"cvss_collateraldamagepotential":null,"cvss_targetdistribution":null,"cvss_securityrequirementscr":null,"cvss_securityrequirementsir":null,"cvss_securityrequirementsar":null,"cvss_basescore":null,"cvss_basevector":null,"cvss_temporalscore":null,"cvss_environmentalscore":null,"cvss_environmentalvector":null,"metric":null,"vulnote":207}