Overview

The binary-parser library for Node.js contains a code injection vulnerability that may allow arbitrary JavaScript code execution if untrusted input is used to construct parser definitions. Versions prior to 2.3.0 are affected. The issue has been resolved by the developer in a public update.

Description

binary-parser is a JavaScript library to facilitate writing "efficient binary parsers in a simple and declarative manner." binary-parser (versions < 2.3.0) dynamically generates JavaScript code at runtime using the Function constructor. Certain user-supplied values—specifically, parser field names and encoding parameters—are incorporated into this generated code without validation or sanitization.

If an application passes untrusted or externally supplied data into these parameters, the unsanitized values can alter the generated code, enabling execution of attacker-controlled JavaScript. Applications that use only static, hardcoded parser definitions are not affected.

The vendor has released a fix and clarified the library’s design limitations in version 2.3.0.

Impact

In affected applications that construct parser definitions using untrusted input, an attacker may be able to execute arbitrary JavaScript code with the privileges of the Node.js process. This could allow access to local data, manipulation of application logic, or execution of system commands depending on the deployment environment.

Solution

Users of the binary-parser library should upgrade to version 2.3.0 or later, where the vendor has implemented input validation and mitigations for unsafe code generation. Developers should avoid passing untrusted or user-controlled values into parser field names or encoding parameters.

Acknowledgements

Thanks to the reporter Maor Caplan for identifying the vulnerability and to Keichi Takahashi for implementing the fix. This document was written by Timur Snoke.

Vendor Information

References

• https://github.com/keichi/
• https://github.com/keichi/binary-parser/pull/283
• https://www.npmjs.com/package/binary-parser

Overview

The Open5GS WebUI component contains default hardcoded secrets used for security-sensitive operations, including JSON Web Token (JWT) signing. If these defaults are not changed, an attacker can forge valid authentication tokens and gain administrative access to the WebUI. This can result in unauthorized access to protected management endpoints.

Description

Open5GS is an open-source implementation of 5G core network functions. It includes an optional WebUI component implemented using Node.js and Next.js for managing configuration and subscriber data. The WebUI relies on multiple secret values provided via Node.js process.env environment variables. These include secrets used for cryptographic operations such as signing and validating JSON Web Tokens (JWTs). By default, these environment variables are initialized to the static value change-me, including the JWT signing secret. JWTs are commonly used to implement authentication and authorization, as well as to securely transmit claims such as user roles and permissions.

In the Open5GS WebUI, these tokens are issued and validated using the default hardcoded secret unless explicitly overridden by the executing environment by the operator. The WebUI, on startup, does not emit warnings or enforce changes to these default secrets. As a result, deployments that do not manually override the defaults will operate with predictable and publicly known cryptographic keys. An attacker with network access to the WebUI can exploit this condition to forge valid administrative JWTs.

While the WebUI includes Cross-Site Request Forgery (CSRF) protections, these controls are ineffective against requests authenticated with valid forged JWTs. The WebUI is commonly deployed in containerized environments and may be assumed to be locally exposed; however, misconfigurations or local access assumptions can still place the interface at risk.

Impact

An unauthenticated network attacker with access to the WebUI component can generate forged JWTs using the known default secret. With these tokens, the attacker can access or modify protected REST endpoints under /api/db/*. This vulnerability allows unauthorized read and write access to sensitive data, including subscriber information and system configuration. CSRF protections do not mitigate this attack, as the forged tokens satisfy authentication requirements. Successful exploitation may result in full access of the WebUI component and all of its permissions.

Solution

For Developers

A patch addressing this issue is available in the following pull request: https://github.com/open5gs/open5gs/pull/4279 against the version v2.7.6 released in July 2025. The patch introduces the use of a self-contained .env file for the WebUI’s Next.js environment and removes reliance on hardcoded default secret values. This ensures that each WebUI deployment generates and uses independent, locally scoped cryptographic secrets, reducing the risk of token forgery and key reuse across instances.

Developers integrating or redistributing the WebUI component are encouraged evaluate, validate and adopt the changes within their own environments prior to deployment

For Users

Users who are unable to apply the patch should manually configure their Node.js environment to define strong, cryptographically secure random values for the following environment variables: - process.env.SECRET_KEY - process.env.JWT_SECRET_KEY These values preferable are unique per deployment and treated as sensitive secrets. Additionally, operators are advised to restrict access to the WebUI by placing it behind appropriate network controls, such as authentication gateways or secure content inspection proxies, to limit exposure from untrusted networks.

Acknowledgements

Thanks to the reporter Andrew Fasano from NIST's Center for AI Standards & Innovation. This document was written by Laurie Tyzenhaus. The software patch was written by Vijay Sarvepalli.

Vendor Information

References

• https://github.com/open5gs/open5gs/pull/4279
• https://github.com/open5gs/open5gs/issues/2264
• https://github.com/open5gs/open5gs/issues/856
• https://github.com/open5gs/open5gs/pull/857

Overview

A stack-based buffer overflow vulnerability exists in GNU libtasn1, a low-level ASN.1 parsing library. The issue is caused by unsafe string concatenation in the asn1_expand_octet_string function located in decoding.c. Under worst-case conditions, this results in a one-byte stack overflow that may corrupt adjacent memory. While the overflow is limited to a single byte, such conditions can still lead to unexpected behavior when processing untrusted ASN.1 input data.

Description

GNU libtasn1 is a low-level C library for manipulating Abstract Syntax Notation One (ASN.1) data structures and encoding rules, including Distinguished Encoding Rules (DER). It implements functionality defined by ITU-T Recommendations X.680 and X.690 and is widely used as a foundational component in cryptographic software stacks to parse and validate complex ASN.1-encoded data.

A stack-based buffer overflow has been identified in the function asn1_expand_octet_string in the file decoding.c. The vulnerability arises from the use of unbounded string manipulation functions (strcpy and strcat) to construct a local stack buffer (name) using the fields definitions->name and p2->name. In the worst-case scenario, both source strings may be at their maximum allowed length. When concatenated together with an additional separator character (".") and a terminating null byte, the destination buffer is undersized by one byte. As a result, the final null terminator written by strcat overflows the allocated stack buffer by a single byte.

Although the overflow is limited in size, it occurs during the parsing of potentially untrusted ASN.1 input. One-byte stack overflows have historically led to subtle memory corruption issues and may cause unexpected behavior, including crashes, during cryptographic operations such as signature verification or certificate parsing.

Impact

An attacker could trigger the buffer overflow using a malformed ASN.1 data to potential corrupt memory or cause unexpected behavior. This requires breaking libtasn1’s assumption that ASN.1 structures passed to it are already validated by the main application using this library. The impact of this vulnerability is limited due to the one-byte nature of the overflow. Exploitation is constrained and may be further mitigated by modern compiler protections such as stack canaries, _FORTIFY_SOURCE, and other hardening mechanisms. However, as the GNU libtasn1 is commonly used in cryptographic libraries and security-sensitive contexts, malformed ASN.1 input triggering this condition could result in parsing failures or abnormal behavior during critical cryptographic operations, including signature verification and cryptographic data validation.

Solution

A patch addressing this issue has been proposed to the GNU libtasn1 project and is available for review and testing at: https://gitlab.com/gnutls/libtasn1/-/merge_requests/121. Developers and integrators are encouraged to evaluate the patch and apply appropriate mitigations, such as using bounded string operations or safer formatting functions, to eliminate the overflow condition in affected versions. Read https://gitlab.com/gnutls/libtasn1/-/blob/master/NEWS.md for updates

Acknowledgements

Thanks to Benny Zelster from Microsoft Research for coordinating the disclosure of this vulnerability.This document was written by Vijay Sarvepalli.

Vendor Information

References

• https://gitlab.com/gnutls/libtasn1
• https://gitlab.com/gnutls/libtasn1/-/merge_requests/121
• https://gitlab.com/gnutls/libtasn1/-/blob/master/NEWS.md
• https://gitlab.com/gnutls/libtasn1/-/blob/master/doc/security/CVE-2025-13151.md

Overview

Kernel driver ProcessMonitorDriver.sys in Safetica's endpoint client x64, versions 10.5.75.0 and 11.11.4.0, allows for an unprivileged user to abuse an IOCTL path and terminate protected system processes.

Description

Safetica is a Data Loss Prevention (DLP) and Insider Risk Management (IRM) software solution that helps organizations protect their data via detecting, analyzing, and mitigating threats. Safetica's platform is AI-powered and is used by public and private organizations, globally.

A vulnerabilty has been discovered in Safetica’s ProcessMonitorDriver.sys kernel driver. A local, unprivileged user can abuse a vulnerable IOCTL (Input/Output Control) path in the kernel driver to cause privileged termination of arbitrary system processes. IOCTL interfaces allow user-mode software to send commands into the kernel space so that the driver can perform specific privileged actions such as terminating processes. Terminating Safetica's processes in endpoint detection and response and antivirus software can blind their clients' security monitoring on their machines. Improper input sanitization and user validation mechanisms can manipulate the kernel driver into privilege escalation and DOS (denial of service).

Impact

A threat actor can leverage this vulnerability and could use the IOCTL path to terminate processes repeatedly. This could lead to a DOS attack and render Safetica's systems unavailable.

Solution

At the time of publication, no vendor-supported fix is available for the vulnerability affecting Safetica DLP kernel driver ProcessMonitorDriver.sys, which allows unprivileged users to abuse exposed IOCTL handlers to terminate arbitrary processes. Until an official patch or guidance is provided by the vendor, the following mitigations are recommended:

1. Monitor and Detect Abuse of IOCTL Calls Targeting the Driver: Safetica's client organizations should actively monitor for suspicious or abnormal IOCTL handler requests. To detect this activity, clients should deploy kernel driver monitoring solutions like Endpoint Detection and Response or System Monitor-like telemetry (where supported). This will 1) identify unprivileged processes, 2) detect unusual IOCTL patterns, and 3) alert security teams when user-mode processes interact with the kernel driver.

2. Restrict or Block Access to the Vulnerable Driver via Policy Controls: To restrict access to ProcessMonitorDriver.sys, Safetica's client organizations should use Windows Group Policy or Application Control policies (WDAC [https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-overview] /AppLocker [https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/applocker/what-is-applocker]). This will prevent untrusted or non-administrative processes from loading or interacting with the driver, through policy-based enforcement mechanisms. These enforcement mechanisms can block untrusted or unsigned binaries from communicating with the kernel driver.

Acknowledgements

Thanks to the reporter, KOSEC LLC. This document was written by Ayushi Kriplani.

Vendor Information

Overview

A Server-Side Template Injection (SSTI) vulnerability exists in the Genshi template engine due to unsafe evaluation of template expressions. Genshi processes template expressions using Python’s 'eval()’ and ‘exec()’ functions while allowing fallback access to Python built-in objects. If an attacker can influence template expressions, this behavior can result in arbitrary code execution on the server.

Description

Genshi is a Python library developed by Edgewall, it provides an integrated set of components for parsing, generating, and processing HTML, XML, or other textual content for output generation on the web. Genshi is most used to render dynamic web pages in Python web frameworks.

Genshi evaluates template expressions, such as ${…}, through an internal expression evaluation mechanism implemented in Genshi’s ‘eval.py’. During expression evaluation, variable resolution is performed by the ‘lookupname()’ method. If a variable is not found in the provided template data, Genshi falls back to resolving the name from Python’s built-in namespace. This namespace includes powerful built-in functions such as globals() ’ and ‘import’. As a result, when an attacker can control or inject template expressions, they may access Python built-in functions and chain them to achieve arbitrary code execution.

Impact

If an attacker can influence or inject template expressions, this vulnerability allows arbitrary code execution with the privileges of the running application. Potential impacts include executing operating commands, deploying reverse shells or web shells, unauthorized access to sensitive data, or full compromise of the affected server. This issue effectively turns SSTI into Remote Code Execution (RCE).

Solution

At the time of publication, Genshi has not released an update addressing this issue. Until an official patch or guidance is provided by the vendor, the following mitigations are recommended:

1. Do not allow untrusted users to control template expressions or template sources. Templates must be treated as executable code.

2. Restrict or eliminate access to Python built-ins during template evaluation.

3. Avoid using ‘eval()’ or ‘exec()’ on dynamically constructed expressions when untrusted input is involved.

4. If user-defined templates are required, render them in a hardened sandbox environment.

Acknowledgements

Thanks to the reporter Jangwoo Choe. This document was written by Michael Bragg.

Vendor Information

References

• https://github.com/edgewall/genshi/

Overview

dr_flac, an open-source FLAC audio decoder, part of the dr_libs audio decoder toolset, contains an integer overflow vulnerability allowing for denial of service (DoS) when provided a specific crafted file. An attacker can exploit this vulnerability through providing a tool that uses dr_flac a specially crafted file, and can cause the tool to crash. The vulnerability, tracked as CVE-2025-14369, has been patched in commit b2197b2 of dr_flac. In an enterprise situation, audio tools that use dr_flac may be susceptible to crashes or other abnormal behavior if they process attacker-controlled files.

Description

dr_libs is an open-source audio decoding tool. It is made of three separate tools, dr_flac, dr_mp3, and dr_wav, which can decode FLAC, MP3, and WAV files respectively.

An integer overflow vulnerability has been discovered, tracked as CVE-2025-14369 within dr_libs. An attacker who can supply crafted input FLAC files to the tool may trigger allocation of a large amount of memory, leading to a crash or unintended function of the tool.

During function, a single block of memory could be allocated to totalPCMFrameCount from the FLAC metadata without validation before the calculation of the bugger size. This could result in a specifically crafted file being allocated an arbitrary amount of memory space.

Impact

An attacker able to send input data in the form of FLAC files to the tool or other input stream that uses dr_flac could cause a crash or DoS attack.

Solution

Commit b2197b2, released on GitHub, fixes the issue. Users should update to the latest version ASAP. All versions prior to commit b2197b2 are affected.

Acknowledgements

Thanks to the reporter who wishes to remain Maor Caplan.This document was written by Christopher Cullen.

Vendor Information

References

• https://github.com/mackron/dr_libs/commit/b2197b2eb7bb609df76315bebf44db4ec2a1aed0