Overview
UEFI firmware applications DTBios and BiosFlashShell from DTResearch contain a vulnerability that allows Secure Boot to be bypassed using a specially crafted NVRAM variable. The vulnerability stems from improper handling of a runtime NVRAM variable that enables an arbitrary write primitive, capable of modifying critical firmware structures, including the global Security2 Architectural Protocol used for Secure Boot verification.. Because the affected applications are signed by the Microsoft UEFI Certificate Authority, this vulnerability can be exploited on any UEFI-compliant system, allowing unsigned code to run during the boot process.
Description
Unified Extensible Firmware Interface (UEFI) defines a modern firmware architecture that facilitates interaction between a computer’s hardware and its operating system during early boot. When a UEFI-compliant system starts, UEFI applications and drivers are executed to initialize the system and hand off control to the operating system (OS) loader. These UEFI applications must be signed and verified for execution under Secure Boot. These signatures can originate from the OEM or from entries in the system’s signature database (DB), which commonly includes the Microsoft UEFI Certificate Authority (CA).
UEFI defines extensible NVRAM variables that store configuration, device customization, and runtime context shared across UEFI applications and the operating system. A vulnerability was identified in a Microsoft-signed UEFI application that uses the NVRAM variable IhisiParamBuffer as a pointer for memory operations, including overwriting the critical global security parameter gSecurity2 . This allows bypassing Security2 Architectural Protocol-based verification , enabling the execution of any unsigned UEFI binaries irresepective of UEFI Secure Boot settings.
In some implementations, IhisiParamBuffer is locked early during boot, preventing modification at runtime. However, as Binarly observed, the vulnerability can be exploited in environments where the IhisiParamBuffer NVRAM variable is not locked and remains writable at runtime. In such cases, attackers can bring and execute the vulnerable UEFI application even on systems with Secure Boot enabled—using a Bring Your Own Vulnerable Driver (BYOVD) approach. Initially the vulnerability was reported on DTResearch’s Dtbios application version 71.22 for 64-bit architecture, however Microsoft has further identified that this vulnerability is present in both DtBios and BiosFlashShell on multiple versions. A total of 14 hashes have been added to the Forbidden Signature Database (DBX or Revocation List) to address these various binaries.
To mitigate this vulnerability, affected UEFI modules must be updated via vendor-provided software. Additionally, all UEFI-compliant system owners should update their Secure Boot Forbidden Signature Database (DBX or Revocation List), which is available via OEM updates, Microsoft, or the Linux Vendor Firmware Service (LVFS).
Impact
An attacker with the ability to modify the IhisiParamBuffer NVRAM variable can use it to perform arbitrary memory writes, enabling a Secure Boot bypass during early boot. This allows unsigned or malicious code to run before the OS loads, potentially installing persistent malware or kernel rootkits that survive reboots and OS reinstallations. Because this attack occurs before OS-level security tools initialize, it can evade detection by endpoint detection and response (EDR) systems. In some cases, it can even entirely disable EDR systems by modifying low-level interfaces before they load.
Solution
Apply a Patch
Multiple vendors have released software updates to address this vulnerability and prevent potential exploitation. Please refer to the Vendor Information section for applicable updates. Microsoft has also indicated they will release an updated DBX (Revocation List) file to prevent vulnerable components from being executed under Secure Boot. Windows Users can further use Check-UEFISecureBootVariables PowerShell scripts to verify whether the latest DBX updates can be applied. For Linux users, LVFS has released a blog article to detail revocation list updates through the Linux tools provided by the fwupd project.
Recommendations for Enterprises and Developers
Changes to the DBX (Forbidden Signature Database) may cause system boot failures if not carefully managed. Vendors should thoroughly test updates to ensure system stability. In some cases, it may be necessary to update the DB (Signature Database) before updating the DBX, as described in Microsoft’s KB5025885. Enterprises and cloud providers managing broad deployments of systems should prioritize these updates and confirm DBX revocation is enforced, particularly in virtualized environments, to block unauthorized UEFI binaries during early boot phases.
Acknowledgements
Thanks to Binarly REsearch team for the responsible disclosure of this vulnerability to CERT/CC. Thanks also to Microsoft and various vendors for their collaboration and timely response. This document was written by Vijay Sarvepalli.

Overview
An out-of-bounds (OOB) read vulnerability has been identified in the Trusted Platform Module (TPM) 2.0 reference library specification, currently at Level 00, Revision 01.83 (March 2024). An attacker with access to a TPM command interface can exploit this vulnerability by sending specially crafted commands, potentially leading to unauthorized access to sensitive data or denial of service of the TPM.
Description
Trusted Platform Module (TPM) technology is a hardware-based solution that provides secure cryptographic functions to operating systems on modern computing platforms. Designed to resist tampering, TPM can be implemented as a discrete chip, integrated component, or firmware-based module. Software-based implementations are also available to support the cryptographic needs of cloud and virtualized environments. The Trusted Computing Group (TCG) maintains the TPM specifications and provides a reference implementation to assist vendor adoption.
A Security researcher have discovered an OOB read vulnerability in the CryptHmacSign function of the reference implementation. The issue arises because the reference code did not implement appropriate consistency checks in CryptHmacSign function resulting in potential out-of-bound read. An attacker with access to the TPM interface can exploit this mismatch by submitting a maliciously crafted packet, resulting in an out-of-bounds read from TPM memory, which may expose sensitive data.
Impact
An authenticated local attacker can send malicious commands to a vulnerable TPM interface, resulting in information disclosure or denial of service of the TPM. The impact assessment depends on the vendor specific implementation.
Solution
The TCG has released an errata update to the TPM 2.0 Library Specification and updated the reference implementations to address this vulnerability. Users are strongly encouraged to apply TPM-related firmware updates provided by their hardware or system vendors. Please refer to the Vendor Information section for any specific guidance from affected vendors. TPM2.0 vendors are urged to use the latest specifications and the reference implementation to ensure these vulnerabilities are resolved in their implementations. TCG has published VRT009 advisory and uses VRT0009 to track this advisory.
libtpms open source
See also related CVE-2025-49133 and the patch commit 04b2d8e for the opensource libtpms 0.10.1 released.
Acknowledgements
Thanks to the reporter, who wishes to remain anonymous. This document was written by Vijay Sarvepalli.

Overview
A vulnerability in an Insyde H2O UEFI firmware application allows digital certificate injection through an unprotected NVRAM variable. This issue arises from the unsafe use of an NVRAM variable, which is used as trusted storage for a digital certificate in the trust validation chain. An attacker can store their own certificate in this variable and subsequently run arbitrary firmware (signed by the injected certificate) during the early boot process within the UEFI environment.
Description
Unified Extensible Firmware Interface (UEFI) defines a modern firmware architecture that facilitates interaction between a computer’s hardware and its operating system during early boot. When a UEFI-compliant system starts, UEFI applications and drivers are executed to initialize the system and hand off control to the operating system (OS) loader. These UEFI applications must be signed and verified for execution under Secure Boot. These signatures can originate from the OEM or from entries in the system’s signature database (DB), which commonly includes the Microsoft UEFI Certificate Authority (CA).
UEFI defines extensible NVRAM variables that store configuration, device customization, and runtime context shared across UEFI applications and the operating system. A vulnerability was identified in a firmware application due to the use of an untrusted NVRAM variable, SecureFlashCertData, to store and exchange public keys. Because this NVRAM variable is not protected (i.e., not locked), it can be updated at runtime—allowing an attacker to inject their own keys.
As described by the security researcher Nikolaj Schlej

The origin of this vulnerability is the fact that Insyde H2O authors decided to use volatile NVRAM as trusted storage for data exchange between the points of loading the signing certificates from the FW (which can happen in many places in multiple DXE drivers) and verifying the signature of platform tools and update capsules (which happens in a library implementing LoadImage/StartImage pair). Due to use of common library functions (akin LibGetVariable), there’s no way for LoadImage to ensure that the NVRAM variables it consults are indeed volatile and had been previously set by the firmware itself, so hijacking them becomes a trivial “set the very same variables as non-volatile from OS environment”, which the PoC tool performs if ran from Windows Administrator terminal. Any other means to write the same variables to non-volatile NVRAM (i.e. Linux efivars subsystem) will also work the same way.

To mitigate this vulnerability, affected UEFI modules must be updated via vendor-provided firmware updates. Firmware security analysis tools can also inspect affected variables in firmware images to assess exposure to this vulnerability. Note that UEFI variable locking, while supported in some implementations, is currently poorly documented or as it stands unavailable with reference implementations for vendors to adopt.
Impact
An attacker with the ability to modify the SecureFlashCertData NVRAM variable at runtime can use it to inject their digital certificate and bypass Secure Boot. This allows unsigned or malicious code to run before the OS loads, potentially installing persistent malware or kernel rootkits that survive reboots and OS reinstallations. Because this attack occurs before OS-level security tools initialize, it can evade detection by endpoint detection and response (EDR) systems. In some cases, it may even disable EDR systems entirely by modifying low-level interfaces before they load.
Solution
Due to the supply-chain redistribution of this firmware application across multiple Original Device Manufacturers (ODMs) and Original Equipment Manufacturers (OEMs), the vulnerability may be present in multiple PC models. Please check the Vendor Information section for details.
Acknowledgements
Thanks to researcher Nikolaj Schlej for the responsible disclosure of this vulnerability to CERT/CC. Thanks also to Insyde and other vendors for addressing the vulnerability with appropriate actions. This document was written by Vijay Sarvepalli.