UEFI BIOS flaws: SecureBoot bypass and firmware replacement possible

Two different vulnerabilities in various UEFI BIOS versions from several providers allow the SecureBoot mechanism to be bypassed. Attackers can even replace the firmware in UEFI BIOSes from Insyde. Vulnerable systems can thus be completely compromised. Proof-of-concept code for this is publicly available. System manufacturers are working on BIOS updates to close the gaps.

In both cases that have now come to light, the vulnerabilities are due to the misuse of unprotected NVRAM variables. Attackers can manipulate these, even though the UEFI BIOS treats them as trustworthy –, which allows systems to be compromised.

UEFI components from different manufacturers are vulnerable

UEFI firmware is composed of multiple components, often from multiple vendors. As CERT explains in a security advisory issued on Tuesday this week, the vulnerabilities in the UEFI firmware apps "DTBios" and "BiosFlashShell" from DTResearch allow SecureBoot to be bypassed. "The vulnerability stems from improper handling of a runtime NVRAM variable that can be written arbitrarily. This can alter critical firmware structures, including the global Security2 architecture protocol that SecureBoot verification uses. Since the affected UEFI apps are signed by the Microsoft UEFI certification authority, this vulnerability can be exploited on any UEFI-compatible system, allowing unsigned code to be executed during the boot process," the CERT summarizes the problem (CVE-2025-3052 / EUVD-2025-17820, CVSS 8.2, risk "high").

More specifically, the description states that the Microsoft-signed UEFI apps use the NVRAM variable "IhisiParamBuffer" as a pointer for memory operations –, including overwriting the global security parameter "gSecurity2". This allows bypassing the Security2 architecture protocol-based verification that uses the LoadImage function to enforce SecureBoot, and executing any unsigned UEFI binary regardless of the SecureBoot setting of the UEFI bios. Some implementations lock the variable "IhisiParamBuffer" early in the boot process ("lock" the variable), but where this does not happen, the vulnerability can be abused. The discoverers of the Binarly vulnerability have published an in-depth analysis online. Microsoft has added 14 new hashes to the DBX database of "forbidden signatures", which should prevent the vulnerable UEFI apps from being executed. Software updates from the providers provide a remedy. According to current knowledge, this is DTResearch, which provides updated components "DTBios" and "BiosFlashShell", especially for the Insyde BIOSes. CERT maintains a list of affected and unaffected vendors in the security advisory.

Vulnerability in Insyde H2O UEFI app

In an Insyde H2O UEFI firmware app, however, attackers can infiltrate digital certificates due to insecure use of an NVRAM variable. The CERT summarizes the details in its announcement. The firmware apps regard the variable "SecureFlashCertData" as trusted memory for digital certificates in the chain of trust. However, attackers can store their own certificates in it and subsequently run any firmware that is certified with it – already in the early BBoot process within the UEFI environment (CVE-2025-4275 / EUVD-2025-18070, CVSS 7.8, risk "high"). The discoverer of the vulnerability has given it a nickname, "Hydroph0bia" as a pun on "Insyde H2O" (H_2O as the chemical formula for water). In his own detailed analysis, he also provides proof-of-concept (PoC) code to demonstrate the abuse of the vulnerability.

The problem stems from the fact that some UEFI firmware apps trust the contents of the variable "SecureFlashCertData" even though it is not locked. "The problem stems from the fact that the developers of Insyde H2O rely on volatile NVRAM for the trusted memory for the data exchange between the individual stations for loading the certificates by the firmware and verifying the signatures of platform tools and update capsules. By using common library functions such as 'LibGetVariable', 'LoadImage' has no way of ensuring that the NVRAM variables used are actually volatile and have previously been set by the firmware itself. This makes the transfer as trivial as 'set the same variables as non-volatile from the operating system environment', which the PoC tool demonstrates at the Windows administrative prompt. Other variants for writing the variables as non-volatile NVRAM (such as the Linux efivars subsystem) also work in the same way", author Nikolai Schlej explains.

Here too, firmware updates from the manufacturers that update the affected UEFI modules are needed to seal the security gaps.

The CERT points out that the blocking or locking of UEFI variables is only supported in some firmware implementations. It is also poorly documented and not even available in some reference implementations that manufacturers adapt to their systems. The CERT's announcement also contains a gap from affected manufacturers. The Insyde H20 software is actually more widespread.

SecureBoot can be bypassed occasionally, as errors in the implementation of UEFI firmware open up security gaps that attackers can exploit. The BIOS gap "LogoFail" became known around the end of 2023. However, attacks were not quite so trivial there, as logos prepared with malicious code have to be anchored in the EFI system partition (ESP) or in an unsigned part of the firmware.

(dmk)