Currently browsing: Technology

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.

Overview
A stack overflow vulnerability has been discovered within the libexpat open source library. When parsing XML documents with deeply nested entity references, libexpat can recurse indefinitely. This can result in exhaustion of stack space and a crash. An attacker can weaponize this to either perform denial of service (DoS) attacks or memory corruption attacks, based on the libexpat environment and library usage.
Description
libexpat is an Open Source XML parsing library. It is a stream oriented XML parsing library written in the C programming language. It can be used in particular with large files difficult for processing in RAM. A vulnerability has been discovered, tracked as CVE-2024-8176. The vulnerability description can be observed below.
CVE-2024-8176
A stack overflow vulnerability exists in the libexpat library due to the way it handles recursive entity expansion in XML documents. When parsing an XML document with deeply nested entity references, libexpat can be forced to recurse indefinitely, exhausting the stack space and causing a crash. This issue could lead to denial of service (DoS) or, in some cases, exploitable memory corruption, depending on the environment and library usage.
Impact
An attacker with access to software that uses libexpat could provide a XML document to the program and cause a DoS attack or memory corruption attack. libexpat is used in a variety of different software, and by various companies.
Solution
A patch for the vulnerability has been provided in version 2.7.0 of libexpat. Groups that use libexpat can verify their patch using the POCs provided here: https://github.com/libexpat/libexpat/issues/893#payload_generators
Acknowledgements
This vulnerability was reported to us by the maintainer of the project, Sebastian Pipping, to increase awareness. The vulnerability was originally discovered by Jann Horn of Googles Project Zero. Vendors who wish to join the discussion within VINCE can do so here: https://www.kb.cert.org/vince/. This document was written by Christopher Cullen.

Overview
The Radware Cloud Web Application Firewall is vulnerable to filter bypass by multiple means. The first is via specially crafted HTTP request and the second being insufficient validation of user-supplied input when processing a special character. An attacker with knowledge of these vulnerabilities can perform additional attacks without interference from the firewall.
Description
The Radware Cloud Web Application Firewall can be bypassed by means of a crafted HTTP request. If random data is included in the HTTP request body with a HTTP GET method, WAF protections may be bypassed. It should be noted that this evasion is only possible for those requests that use the HTTP GET method.
Another way the Radware Cloud WAF can be bypassed is if an attacker adds a special character to the request. The firewall fails to filter these requests and allows for various payloads to reach the underlying web application.
Impact
An attacker with knowledge of these vulnerabilities can bypass filtering. This allows malicious inputs to reach the underlying web application.
Solution
The vulnerabilities appear to be fixed (see reference URL below). Initially Radware did not acknowledge the reporter’s findings when they were first disclosed. As of June 4, 2025, Radware has reached out to the SEI and has stated that Radware acknowledges the vulnerability and appreciates the responsible disclosure. Additionally, Radware has fixed the issue and published a technical knowledge base article covering the CVE and attributing the discovery to Oriol Gegundez.
Acknowledgements
Thanks to Oriol Gegundez for reporting this issue. This document was written by Kevin Stephens and Ben Koo.

Overview
Digigrams PYKO-OUT audio-over-IP (AoIP) product is used for audio decoding and intended for various uses such as paging, background music, live announcements and others. It has hardware compatibility with two analog mono outputs and a USB port for storing local playlists. The product does not require a password by default, and when opened to the Internet, can allow attackers access to the device, where they can then pivot to attacking adjacent connected devices or compromise the device’s functionality.
Description
Digigram is an audio-based hardware and software vendor, providing various products including sound cards, AoIP gateways, and speaker-related support software. Digigram sells a PYKO-OUT audio-over-IP product that is used for audio decoding and intended for various uses such as paging, background music, and live announcements.
A vulnerability has been discovered within the web-server component of the PYKO-OUT AoIP, where the default configuration does not require any login information or password. This web server spawns on 192.168.0.100 by default. The lack of log-in credentials allows any attacker who discovers the vulnerable IP address of the device to connect and manipulate it, without any authentication or authorization.
An attacker who gains access to the device can access its configuration, control audio outputs and inputs, and potentially pivot to other connected devices, whether this be through network connections, or by placing malicious files in a connected USB device.
Impact
An attacker with access to a vulnerable device can access the devices configuration, control audio-over-IP data streams managed by the device, and pivot to other network and physical connected devices, such as through a connected USB thumb drive.
Solution
Digigram has marked this product as EOL and will not be providing a patch to change the default configuration. Users can alter the password settings within the web server UI and force attempted connections to provide a password. Additionally, the product is no longer being sold by Digigram.
Acknowledgements
Thanks to the reporter, Souvik Kandar. Additional thanks to CERT-FR. This document was written by Christopher Cullen.

Overview
Two systemic jailbreaks, affecting a number of generative AI services, were discovered. These jailbreaks can result in the bypass of safety protocols and allow an attacker to instruct the corresponding LLM to provide illicit or dangerous content. The first jailbreak, called “Inception,” is facilitated through prompting the AI to imagine a fictitious scenario. The scenario can then be adapted to another one, wherein the AI will act as though it does not have safety guardrails. The second jailbreak is facilitated through requesting the AI for information on how not to reply to a specific request.
Both jailbreaks, when provided to multiple AI models, will result in a safety guardrail bypass with almost the exact same syntax. This indicates a systemic weakness within many popular AI systems.
Description
Two systemic jailbreaks, affecting several generative AI services, have been discovered. These jailbreaks, when performed against AI services with the exact same syntax, result in a bypass of safety guardrails on affected systems.
The first jailbreak, facilitated through prompting the AI to imagine a fictitious scenario, can then be adapted to a second scenario within the first one. Continued prompting to the AI within the second scenarios context can result in bypass of safety guardrails and allow the generation of malicious content. This jailbreak, named “Inception” by the reporter, affects the following vendors:

ChatGPT (OpenAI)
Claude (Anthropic)

Copilot (Microsoft)

DeepSeek
Gemini (Google)
Grok (Twitter/X)
MetaAI (FaceBook)
MistralAI

The second jailbreak is facilitated through prompting the AI to answer a question with how it should not reply within a certain context. The AI can then be further prompted with requests to respond as normal, and the attacker can then pivot back and forth between illicit questions that bypass safety guardrails and normal prompts. This jailbreak affects the following vendors:

ChatGPT
Claude

Copilot

DeepSeek
Gemini
Grok
MistralAI

Impact
These jailbreaks, while of low severity on their own, bypass the security and safety guidelines of all affected AI services, allowing an attacker to abuse them for instructions to create content on various illicit topics, such as controlled substances, weapons, phishing emails, and malware code generation.
A motivated threat actor could exploit this jailbreak to achieve a variety of malicious actions. The systemic nature of these jailbreaks heightens the risk of such an attack. Additionally, the usage of legitimate services such as those affected by this jailbreak can function as a proxy, hiding a threat actors malicious activity.
Solution
Various affected vendors have provided statements on the issue and have altered services to prevent the jailbreak.
Acknowledgements
Thanks to the reporters, David Kuzsmar, who reported the first jailbreak, and Jacob Liddle, who reported the second jailbreak. This document was written by Christopher Cullen.