In September 2025, researchers at Binarly released a comprehensive study that challenges the assumption that Secure Boot is impervious to tampering. Secure Boot depends on a chain of trust anchored by signed modules, but Binarly’s team found that a large number of legitimately signed UEFI drivers and shells contain vulnerabilities that can be weaponized to bypass the bootloader and install persistent malware. This revelation means attackers no longer need to forge signatures; they can simply bring their own vulnerable driver to compromise the firmware.
The team examined more than 5,000 UEFI modules in its analysis and identified over 1,500 signed binaries that would be trusted by Secure Boot despite containing exploitable flaws. Binarly categorised these modules into several groups — modules with multiple uses (e.g., boot update and diagnostic functions), fully trusted but unmaintained modules, binaries signed with leaked private keys, modules with verification logic errors, and those that leave debugging features enabled. In some cases Microsoft’s own third‑party certificate authority signed vulnerable shells, underscoring systemic weaknesses in the industry’s trust model.
These UEFI issues parallel the Bring Your Own Vulnerable Driver (BYOVD) technique used in Windows: adversaries load a legitimately signed but vulnerable driver or shell to bypass secure boot controls. In the firmware context, attackers can abuse signed UEFI shells or driver packages to break Secure Boot, execute arbitrary code before the operating system loads and install stealthy rootkits that persist across reboots. Because Secure Boot treats all signed modules as equally trustworthy, revocation is rare and vulnerabilities remain exploitable for years.
Binarly warns that these findings indicate a need for stronger safeguards throughout the firmware supply chain. Vendors should audit all signed modules for vulnerabilities prior to release, regularly revoke certificates for outdated or compromised drivers and adopt hardware‑based protections such as Intel Boot Guard. Administrators can mitigate risk by disabling unused boIn September 2025, researchers at Binarly released a comprehensive study that challenges the assumption that Secure Boot is impervious to tampering. Secure Boot depends on a chain of trust anchored by signed modules, but Binarly’s team found that a large number of legitimately signed UEFI drivers and shells contain vulnerabilities that can be weaponized to bypass the bootloader and install persistent malware. This revelation means attackers no longer need to forge signatures; they can simply bring their own vulnerable driver to compromise the firmware.
The team examined more than 5,000 UEFI modules in its analysis and identified over 1,500 signed binaries that would be trusted by Secure Boot despite containing exploitable flaws. Binarly categorised these modules into several groups — modules with multiple uses (e.g., boot update and diagnostic functions), fully trusted but unmaintained modules, binaries signed with leaked private keys, modules with verification logic errors, and those that leave debugging features enabled. In some cases Microsoft’s own third‑party certificate authority signed vulnerable shells, underscoring systemic weaknesses in the industry’s trust model.
These UEFI issues parallel the Bring Your Own Vulnerable Driver (BYOVD) technique used in Windows: adversaries load a legitimately signed but vulnerable driver or shell to bypass secure boot controls. In the firmware context, attackers can abuse signed UEFI shells or driver packages to break Secure Boot, execute arbitrary code before the operating system loads and install stealthy rootkits that persist across reboots. Because Secure Boot treats all signed modules as equally trustworthy, revocation is rare and vulnerabilities remain exploitable for years.
Binarly warns that these findings indicate a need for stronger safeguards throughout the firmware supply chain. Vendors should audit all signed modules for vulnerabilities prior to release, regularly revoke certificates for outdated or compromised drivers and adopt hardware‑based protections such as Intel Boot Guard. Administrators can mitigate risk by disabling unused boot options, restricting boot device selection and monitoring for anomalous firmware updates. Ultimately, trust in Secure Boot cannot rely on signatures alone; continuous vulnerability assessment and responsive revocation policies are essential.
Sources:
[1] Binarly – “Signed and Dangerous: BYOVD Attacks on Secure Boot” (10 Sept 2025) – https://binarly.io/posts/2025/09/signed-and-dangerous-byovd-attacks-on-secure-boot
redsec.ninja 
Leave a comment