Currently browsing: Security

Overview
Multiple vulnerabilities have been identified in Ruckus Wireless 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. At this time, we have not able to reach Ruckus Wireless or their parent company to include their response to these disclosed vulnerabilities, we recommend using these products only within isolated management networks accessible to trusted users.
Description
Ruckus Wireless 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 Wireless 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 Wireless 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-44954] Unauthenticated RCE in SSH due to Hardcoded Default Public/Private Keys (CWE-1394: Use of Default Cryptographic Key). Ruckus vSZ has a built-in user with all of the same privileges as root. This user also has default public and private RSA keys in its /home/$USER/.ssh/ directory. Anyone with a Ruckus device would also have this private key and be able to ssh as this and then have root-level permissions.
[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 network access to Ruckus Wireless vSZ can exploit CVE-2025-44954 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
No patches have been supplied by the vendor at this time.
To mitigate risk, network administrators should limit access to the wireless management environments that use these affected products, allowing a limited set of trusted users and their authenticated clients to manage Ruckus infrastructure via a secure protocol such as HTTPS or SSH.
Acknowledgements
Thanks to Noam Moshe of Claroty Team82 for reporting these vulnerabilities. This document was written by CERT/CC.

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.