Author Archives: CERT

Overview

Partner Software and Partner Web, both products of their namesake company, Partner Software, fail to sanitize report or note files, allowing for XSS attacks. Partner Software is subdivision of N. Harris Computer Corporation and is a field application development company, with products intended for use by industry, municipalities, state government, and private contractors. An authorized user of Partner Software or Partner Web application can upload “Reports” when viewing a job. The file upload feature does not limit files that can be uploaded or their extensions, allowing an attacker with valid credentials to perform XSS attacks and execute malicious code on the device. The Partner Web product also ships with the same default administrator username and password across versions. An attacker with access to the Partner Web application could abuse these vulnerabilities to perform arbitrary code execution on the hosting device.

Description

Partner Software’s products Partner Software and Partner Web are used by various municipalities, state government, and private contractors for field application work. These products include support for various GIS-related uses, map viewers, and other support tools. The Partner Software and Partner Web products contain various fields for uploading content for analysis by field workers. An authenticated user with access to the Partner Web application could perform RCE through usage of the vulnerabilities.

CVE-2025-6076
Partner Software’s corresponding Partner Web application does not sanitize files uploaded on the Reports tab, allowing an authenticated attacker to upload a malicious file that will be stored on the victim server.

CVE-2025-6077
Partner Software’s corresponding Partner Web application all use the same default username and password for the administrator account.

CVE-2025-6078
Partner Software/Partner Web allows an authenticated user to add text on the Notes page within the Job view, but does not completely sanitize input, making it possible to add notes with HTML tags and JavaScript and enabling an attacker to add a note containing malicious JavaScript, leading to stored XSS (cross-site scripting).

Impact

An attacker using these vulnerabilities can either gain administrator access to the device or perform XSS, compromising the device.

Solution

Partner Software has provided a patch for the affected product in version 4.32.2. The Admin and Edit users are now removed in the 4.32.2 patch, and the Notes section now restricts and sanitizes input to only including simple text. Additionally, file attachments allowed include only .csv, .jpg, .png, .txt, .doc, and .pdf files, and will not longer read then files, only display them. The affected versions of Partner Web are 4.32 and previous. Patch information is available here: https://partnersoftware.com/resources/software-release-info-4-32/

Acknowledgements

Thanks to the reporter, Ryan Pohlner (Cybersecurity and Infrastructure Security Agency). for the report and to Partner Software for coordination efforts. This document was written by Christopher Cullen.

Continue reading VU#317469: Partner Software/Partner Web does not sanitize Report files and Note content, allowing for XSS and RCE→

Overview

The TP-Link Archer C50 router, which has reached End-of-Life (EOL), contains a hardcoded encryption key in its firmware, enabling decryption of sensitive configuration files. This vulnerability allows attackers to trivially access administrative credentials, Wi-Fi passwords, and other internal settings, after authentication to the device.

Description

A vulnerability exists in the TP-Link Archer C50 router’s firmware, where encrypted configuration files are protected using DES in ECB (Electronic Codebook) mode with a hardcoded static key. The embedded DES key is never randomized or derived per device.

CVE-2025-6982
TP-Link Archer C50 router contains hardcoded DES decryption keys, which makes them vulnerable to configuration file decryption.

The encryption lacks randomness and message authentication, allowing for trivial offline decryption of sensitive data.

Impact

Exploitation of this vulnerability may result in:

Exposure of Sensitive Configuration Data

• Admin credentials
• Wireless network SSIDs and passwords
• Static IPs, DHCP settings, and DNS server details

Network Intelligence Gathering

• Internal network structure
• Connected device roles and topology
• Pre-positioning for further attacks

Ease of Exploitation

• Works on default firmware configurations
• Does not require the router to be actively running
  Primary Impact: Full authorized access to router configuration, leading to potential compromise of the connected network.

Solution

The CERT/CC is currently unaware of a practical solution to this problem.
Note: The TP-Link Archer C50 has reached End-of-Life (EOL) and no longer receives firmware updates or security support from the vendor.

Users are strongly advised to:

• Retire and replace the Archer C50 with a supported router model
• Avoid using devices with known cryptographic flaws
• Secure or delete any exported configuration files
• Change passwords if configuration files were exposed or restored from backup

Acknowledgements

Thanks to the researchers Sushant Mane, Jai Bhortake, and Dr. Faruk Kazi from CoE – CNDS Lab, VJTI, Mumbai, India. This document was written by Timur Snoke.

Continue reading VU#554637: TP-Link Archer C50 router is vulnerable to configuration-file decryption→

Overview

Lakeside Software, an IT digital employee experience platform, offers a product called SysTrack, intended for endpoint observability. This program uses an executable called LsiAgent.exe, which attempts to load various Dynamic Link Library (DLL) files when run. The program does not properly check which files or places from which it loads the DLL files, allowing an attacker to place a malicious DLL file within a known System PATH variable on the victim device. When LsiAgent.exe runs, it will load the malicious code, resulting in code execution and privilege escalation, as LsiAgent.exe runs within the NT AUTHORITY\SYSTEM context. A patch has been provided by Lakeside Software, and the vulnerability is fixed in version 10.10.0.42 and higher.

Description

Lakeside Software, an IT digital employee experience company, offers a product called Systems Management Agent (SysTrack) that is intended for endpoint health and performance monitoring. The product contains various different programs and executables that are installed on a device. One of these programs is called LsiAgent.exe, which runs within the context of NT AUTHORITY\SYSTEM. Additionally, LsiAgent.exe runs on startup with default installation settings. A vulnerability has been discovered, tracked as CVE-2025-6241, which allows an attacker to achieve elevated code execution through placing malicious DLL files within a known System PATH environment variable, or by bundling the LsiAgent.exe program alongside another malicious DLL. The bundled DLL will be executed when the victim runs the supposedly safe LsiAgent.exe program.

System PATH variable settings are typically manipulated by other programs installed during normal use of a machine. When LsiAgent.exe is executed, it will iterate through the System PATH environment variable to search for a DLL titled ‘wfapi.dll.’ SysTrack uses the wdapi.dll file to verify if the system is running in a virtualized Citrix Environment. During the System PATH iteration process, LsiAgent.exe attempts to load and run the first file named wfapi.dll that it encounters within the System PATH variable. Therefore, an attacker would only need to provide their malicious DLL file named wfapi.dll within one of the System PATH variables to achieve code execution.

Impact

An attacker with the ability to place a file within any known System PATH environment variable on a victim machine can achieve remote code execution and privilege escalation, as LsiAgent.exe runs within the NT AUTHORITY\SYSTEM context. Furthermore, LsiAgent.exe is a signed program, so operations carried out by the program will be shown as being done by a legitimate program, heightening potential impact.

Solution

A patch has been provided by Lakeside Software to fix the affected LsiAgent.exe program. The vulnerable version, 10.05.0027, has been fixed in versions 10.10.0.42 and higher of LsiAgent.exe. The release notes of the version are available here: https://documentation.lakesidesoftware.com/en/Content/Release%20Notes/Agent/10_10_0%20Hotfix%20Agent%20Release%20Notes%20On%20Premises.htm?tocpath=Release%20Notes%7CAgent%7C_____13

Acknowledgements

Thanks to the reporter Owen Sortwell and contributors Adam Merrill and Brian Healy of Sandia National Laboratories. This document was written by Christopher Cullen.

Continue reading VU#335798: SysTrack LsiAgent.exe contains an improper DLL search order, allowing an attacker to execute arbitrary code and priv esc→

Overview

System Management Mode (SMM) callout vulnerabilities have been identified in UEFI modules present in Gigabyte firmware. An attacker could exploit one or more of these vulnerabilities to elevate privileges and execute arbitrary code in the SMM environment of a UEFI-supported processor. While AMI (the original firmware supplier) has indicated that these vulnerabilities were previously addressed, they have resurfaced in Gigabyte firmware and are now being publicly disclosed.

Description

The Unified Extensible Firmware Interface (UEFI) specification defines an interface between an operating system (OS) and platform firmware. UEFI can interact directly with hardware using System Management Mode (SMM), a highly privileged CPU mode designed for handling low-level system operations. SMM operations are executed within a protected memory region called System Management RAM (SMRAM) and are only accessible through System Management Interrupt (SMI) handlers.

SMI handlers act as a gateway to SMM and process data passed via specific communication buffers. Improper validation of these buffers or untrusted pointers from CPU save state registers can lead to serious security risks, including SMRAM corruption and unauthorized SMM execution. An attacker could abuse these SMI handlers to execute arbitrary code within the early boot phases, recovery modes, or before the OS fully loads.

The following vulnerabilities were identified in Gigabyte firmware implementations:

• CVE-2025-7029 : Unchecked use of the RBX register allows attacker control over OcHeader and OcData pointers used in power and thermal configuration logic, resulting in arbitrary SMRAM writes. (BRLY-2025-011)
• CVE-2025-7028 : Lack of validation of function pointer structures derived from RBX and RCX allows attacker control over critical flash operations via FuncBlock, affecting functions like ReadFlash, WriteFlash, EraseFlash, and GetFlashInfo. (BRLY-2025-010)
• CVE-2025-7027 : Double pointer dereference vulnerability involving the location of memory write from an unvalidated NVRAM Variable SetupXtuBufferAddress NVRAM and the content for write from from an attacker-controlled pointer based on the RBX register, can be used write arbitrary content to SMRAM. (BRLY-2025-009)
• CVE-2025-7026 : Attacker-controlled RBX register used as an unchecked pointer within the CommandRcx0 function allows writes to attacker-specified memory in SMRAM. (BRLY-2025-008)

According to AMI, these vulnerabilities were previously addressed via private disclosures, yet the vulnerable implementations remain in some OEM firmware builds such as in the case of Gigabyte. Gigabyte has issued updated firmware to address the vulnerabilities. Users are strongly advised to visit the Gigabyte support site to determine if their systems are affected and to apply the necessary updates.

Impact

An attacker with local or remote administrative privileges may exploit these vulnerabilities to execute arbitrary code in System Management Mode (Ring -2), bypassing OS-level protections. These vulnerabilities can be triggered via SMI handlers from within the operating system, or in certain cases, during early boot phases, sleep states, or recovery modes—before the OS fully loads.

Exploitation can disable UEFI security mechanisms such as Secure Boot and Intel BootGuard, enabling stealthy firmware implants and persistent control over the system. Because SMM operates below the OS, such attacks are also difficult to detect or mitigate using traditional endpoint protection tools.

Solution

Install the latest UEFI firmware updates provided by your PC vendor. Refer to the Vendor Information section below and Gigabyte’s security website for specific advisories and update instructions. Because these vulnerabilities may affect firmware supplied through the supply chain, other PC OEM vendors may also be impacted. Monitor the Vendor Information section for updates as they become available.

Acknowledgements

We thank the Binarly REsearch team for responsibly disclosing these vulnerabilities to CERT/CC. We also acknowledge Gigabyte’s PSIRT for their collaboration and timely response. This document was written by Vijay Sarvepalli.

Continue reading VU#746790: SMM callout vulnerabilities identified in Gigabyte UEFI firmware modules→

Overview

Multiple vulnerabilities have been identified in RUCKUS Networks management products, specifically Virtual SmartZone (vSZ) and Network Director (RND), including authentication bypass, hardcoded secrets, arbitrary file read by authenticated users, and unauthenticated remote code execution. These issues may allow full compromise of the environments managed by the affected software.

For the latest information, please see RUCKUS Security Bulletin 20250710.

Description

RUCKUS Networks is a company that provides networking devices for venues where many end points will be connected to the internet, such as schools, hospitals, multi-tenant residences, and smart cities that provide public Wi-Fi. Virtual SmartZone (vSZ) by RUCKUS Networks is a wireless network control software to virtually manage large-scale networks, up to a scale of 10,000 RUCKUS access points and 150,000 connected clients. RUCKUS Network Director (RND) is software for the management of multiple vSZ clusters on a single network.

Multiple vulnerabilities were reported in these RUCKUS Networks products that are described here:

[CVE-2025-44957] Hardcoded Secrets, including JWT Signing Key, API keys in Code (CWE-287: Improper Authentication). Multiple secrets are hardcoded into the vSZ application, making them vulnerable to access thus allowing elevated privileges. Using HTTP headers and a valid API key, it is possible to logically bypass the authentication methods, providing administrator-level access to anyone that does this.

[CVE-2025-44962] Authenticated Arbitrary File Read (CWE-23: Relative Path Traversal). RUCKUS vSZ allows for users to download files from an allowed directory, but by hardcoding a directory path, a user could traverse other directory paths with ../ to read sensitive files.

[CVE-2025-44960] Remote Code Execution (CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)). A parameter in a vSZ API route is user-controlled and not sanitized before being executed in an OS command. An attacker could supply a malicious payload to result in code execution.

[CVE-2025-44961] Remote Code Execution (CWE-77: Improper Neutralization of Special Elements used in a Command (‘Command Injection’)). An authenticated vSZ user supplies an IP address as an argument to be run in an OS command, but this IP address is not sanitized. A user could supply other commands instead of an IP address to achieve RCE.

[CVE-2025-44963] Hardcoded Secrets, including JWT token (CWE-321: Use of Hard-coded Cryptographic Key). RND uses a secret key on the backend web server to ensure that session JWTs are valid. This secret key is hardcoded into the web server. Anyone with knowledge of the secret key could create a valid JWT, thus bypassing the typical authentication to access the server with administrator privileges.

[CVE-2025-44955] Hardcoded Secrets (CWE-259: Use of Hard-coded Password). RND includes a jailed environment to allow users to configure devices without complete shell access to the underlying operating system. The jailed environment includes a built-in jailbreak for technicians to elevate privileges. The jailbreak requires a weak password that is hardcoded into the environment. Anyone with this password can access an RND server with root permissions.

[CVE-2025-6243] Hardcoded SSH Public Key (CWE-321: Use of Hard-coded Cryptographic Key). A built-in user called sshuser, with root privileges, exists on the RND platform. Both public and private ssh keys exist in the sshuser home directory. Anyone with the private key can access an RND server as sshuser.

[CVE-2025-44958] Recoverable passwords (CWE-257: Storing Passwords in a Recoverable Format). RND encrypts passwords with a hardcoded weak secret key and returns the passwords in plaintext. If the server were compromised, an attacker could gain all the plaintext passwords and decrypt them.

Impact

Impact of these vulnerabilities vary from information leakage to total compromise of the wireless environment managed by the affected products. As an example, an attacker with API access to RUCKUS Networks vSZ can exploit CVE-2025-44957 to gain full administrator access that will lead to total compromise of the vSZ wireless management environment. Furthermore, multiple vulnerabilities can be chained to create chained attacks that can allow the attacker to combine attacks to bypass any security controls that prevent only specific attacks.

Solution

RUCKUS has provided patches defined per product at https://webresources.commscope.com/download/assets/FAQ+Security+Advisory%3A+ID+20250710/225f44ac3bd311f095821adcaa92e24e.

Furthermore, RUCKUS advises deploying
vSZ and RND in accordance with best security practices and also restricting network access to potentially vulnerable devices to a limited set of trusted users.

Acknowledgements

Thanks to Noam Moshe of Claroty Team82 for reporting these vulnerabilities. This document was written by CERT/CC.

Continue reading VU#613753: RUCKUS Virtual SmartZone (vSZ) and RUCKUS Network Director (RND) contain multiple vulnerabilities→

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.

Continue reading VU#806555: A Vulnerability in UEFI Applications allows for secure boot bypass via misused NVRAM variable→

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.

Continue reading VU#282450: Out-of-Bounds read vulnerability in TCG TPM2.0 reference implementation→

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.

Continue reading VU#211341: A vulnerability in Insyde H2O UEFI application allows for digital certificate injection via NVRAM variable→

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.

Continue reading VU#760160: libexpat library is vulnerable to DoS attacks through stack overflow→

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.

Continue reading VU#722229: Radware Cloud Web Application Firewall Vulnerable to Filter Bypass→