New Paper on "BYOVD, but in firmware. Signed UEFI shells, vulnerable modules offer new paths for Secure Boot bypasses."
Binarly has a new (hours-old) paper "on the fragile foundation of UEFI ecosystem." Fabio Pagani and Yegor Vasilenko have just published "Signed and Dangerous: BYOVD Attacks on Secure Boot" and to quote:
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.
Further down, below this overview:
Finding Secure Boot bypasses
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.
This is not security; it's a bloody circus! One might say digital "security theatre". █