By Fabio Pagani, Yegor Vasilenko
The Binarly REsearch team conducted an analysis of signed UEFI modules and the findings show the true scale of the attack surface hidden inside Secure Boot’s trust model. Across thousands of firmware images, we found that modern platforms typically trust approximately 1,500 signed modules, with some builds peaking above 4,000.
That trust isn’t just theoretical. Among these modules we identified the known Secure Boot bypass (CVE-2025-3052), as well as 30 UEFI shells trusted by hundreds of different devices, a finding that has not been publicly discussed to date. These results highlight how the effectiveness of Secure Boot depends not only on cryptographic signatures but also on the security of the signed applications themselves. A vulnerability in any one of these modules could be weaponized to break the chain of trust.
This problem echoes what’s long been observed in Windows with BYOVD (Bring Your Own Vulnerable Driver) attacks. Signed drivers with exploitable flaws can give attackers kernel-level execution while bypassing security checks, a technique documented by VMware TAU, Cisco Talos, and others. The same principle now applies at the firmware layer where signed but vulnerable UEFI modules create a new pathway for persistence and privilege escalation.
In this post, we map the landscape, show where the risks reside, and explain why signed UEFI shells represent a systemic weakness rather than isolated mistakes.
Before diving into the technical details, we introduce a new taxonomy of attacks against Secure Boot and signature verification systems found in software and firmware. This taxonomy is intended to help the industry better understand both the threat model and the attack surface exposed by these systems. These categories are based on our experience and previous findings:
The following list has an example for each of the previous categories:
While the taxonomy is mostly based on our previous findings and might be incomplete, we believe it represents a solid starting point. In this blog, we focus mostly on double-use modules and trusted but vulnerable modules in the context of UEFI, since both categories are central to BYOVD. In particular, we will show how we discovered these modules and how they can be leveraged to bypass Secure Boot.
Creating a dataset of UEFI firmware and modules was the first challenge in this research: the larger the dataset, the more signed modules it contains. We built the initial dataset from three sources:
Each file in the dataset was automatically unpacked, allowing extraction of any firmware image or standalone UEFI application. We then indexed every UEFI module in a modules database containing information about the module, including its name, GUID, Authenticode hashes, and certificate data used for signing the module when available. The database contains more than 10 million modules, with around 8900 of them signed.
After building the modules database, the next step was to determine which firmware trusts the modules it contains. From our internal dataset, we analyzed roughly 4000 unique firmware images released over the past four years by major OEMs. These images span a wide range of devices, from consumer hardware to enterprise-grade servers. Using the database, we identified which modules each firmware image would permit to run. To do this, we extracted the db and dbx from the firmware and checked whether they would allow or block execution of the modules (our previous blogpost on this topic explains how the verification works).
In total, the selected firmware allows the execution of 7,157 modules present in the database with 16% of these modules signed by one of the Microsoft UEFI keys (e.g., Microsoft Corporation UEFI CA 2011), while the remainder were signed with OEM keys. Only five modules were unsigned but still trusted, meaning their hashes had been intentionally added to the Secure Boot db.
The next natural step of this REsearch was searching for double-use modules and for trusted but vulnerable modules.
In terms of trusted but vulnerable modules, we found CVE-2025-3052. This already disclosed vulnerability affects a BIOS-flashing tool signed with Microsoft’s third-party UEFI certificate. This tool uses the content of a NVRAM variable as a pointer for memory writes, making it straightforward for an attacker to corrupt memory.
In terms of double-use modules we instead searched for UEFI shells, since it offers a number of potentially dangerous commands, including the built-in mm command. The mm command can be used to write to memory and thus, eventually, to run unsigned code. For example:
Shell> mm 0x11223344 DDCCBBAA -w 4 -mem
This command writes the value 0xAABBCCDD to the memory address 0x11223344. In addition, the UEFI shell automatically executes any commands listed in the startup.nsh file. This behavior allows an attacker to insert arbitrary commands into this file and have them run during the boot process.
In total, we discovered 30 trusted UEFI shells, affecting seven (7) different OEMs and hundreds of devices. Most UEFI shells are allowed to be executed because they are successfully verified against the OEM certificate stored in the Secure Boot signature database db. The only exception is one UEFI shell affecting a specific OEM, which is trusted because its Authenticode hash has been explicitly added to the Secure Boot signature database db. We shared our findings with CERT/CC at the end of August under coordinated vulnerability disclosure principles. We will share full details of the trusted shells and affected devices later this year.
We believe the number of trusted UEFI shells in the wild is likely much higher, as 16 out of 30 discovered shells were identified through a Retrohunt scan on VirusTotal, which is limited to the last year of submissions. This suggests that attackers have a broader opportunity to abuse UEFI shells than current visibility indicates, making the threat surface potentially larger.
The mm command present in the UEFI shell provides a powerful arbitrary write primitive that can be exploited in multiple ways. This command can be used to disable Secure Boot and execute untrusted code.
The core idea is to overwrite the global variable gSecurity2, which is normally pointed to by the Security2 Architectural Protocol. This protocol is used by the `LoadImage` function to enforce Secure Boot. Zeroing out this variable will bypass the signature verification logic, enabling an attacker to load and execute any unsigned UEFI modules.
We developed and tested a simple PoC based on the described idea:
Signed UEFI shells are not new and have been sporadically discovered in the past (e.g., CVE-2023-49721 and CVE-2023-48733). In response to these discoveries, the reference implementation EDK2 disabled building the UEFI shell when support for Secure Boot is enabled. This is a positive step, as it prevents the UEFI shell from being included in the final firmware image.
However, since IBVs and OEMs may use different build configurations that don’t include this recent change, we propose additional measures. Specifically, when Secure Boot is enabled, the UEFI shell should be modified to:
Implementing both of these changes would block attackers even if a UEFI shell is accidentally signed, preventing a remote attacker from bypassing Secure Boot.
While Secure Boot may seem straightforward on paper, it is actually a complex topic with many facets. The Binarly Transparency Platform (BTP) is designed to address a variety of scenarios and empower both product and security teams. In particular, the platform provides:
