Author Archives: CERT

Overview

Version 1.6.1 of the Flash Payments package graphql-upload-minimal is vulnerable to prototype pollution. This vulnerability, located in the processRequest() function, allows an attacker to inject special property names into the operations.variables object and pollute global object prototypes, ultimately impacting the entire Node.js process.

Description

graphql-upload-minimal is a lightweight Node.js middleware package that implements the GraphQL multipart request specification, enabling file uploads in GraphQL servers. It parses multipart/form-data requests and maps uploaded files into the GraphQL operations object, making them accessible to resolvers.
The vulnerability exists in the processRequest() function, which handles multipart file upload requests. It processes a user-supplied map parameter that determines where uploaded files should be placed within the GraphQL operations.variables object.
The issue occurs because user-supplied property paths are not validated before being resolved and written into the target object. Special JavaScript property names such as __proto__, __constructor__, and prototype are not restricted, allowing crafted paths to traverse the prototype chain and modify Object.prototype.
Because Object.prototype is the base prototype from which most JavaScript objects inherit, altering it results in global prototype pollution across the Node.js process. Once polluted, manipulated properties may be inherited by all subsequently created objects for the lifetime of the process.

Impact

Because Object.prototype is the foundational prototype for most JavaScript objects, modifying it can affect the behavior of all Node.js processes. Since the impact extends across the entire Node.js process and persists until the service is restarted, it can potentially result in logic corruption, denial of service, or unintended privilege escalation.

Solution

Users should upgrade to graphql-upload-minimal version 1.6.3 or later, which can be found at https://github.com/flash-oss/graphql-upload-minimal/tree/master . The patched release introduces safeguards to prevent unsafe prototype-chain property assignments during multipart file upload processing.

Acknowledgements

Thanks to Maor Caplan from Alma Security for reporting this vulnerability. This document was written by Michael Bragg.

Continue reading VU#907705: Graphql-upload-minimal has a prototype pollution vulnerability.→

Overview

Two unsafe pickle deserialization vulnerabilities have been discovered in the SGLang open-source project, one within the tool’s multimodal generation module and another within the Encoder Parallel Disaggregation system. SGLang is a serving framework for large language models (LLMs) and multimodal models. These vulnerabilities, tracked as CVE-2026-3059 and CVE-2026-3060, allow an attacker to provide a malicious pickle file to a device using SGLang’s multimodal generation system or the encoder parallel disaggregation system, enabling code execution. CVE-2026-3989 allows an attacker to provide a malicious pickle file that, when attempted to be replayed with the replay_request_dump.py script, will result in code execution. Version 0.5.10 addresses the vulnerabilities. It is recommended that project maintainers avoid implementing Pickle functions due to the inherent security risks.

Description

SGLang is a framework for serving various large language models (LLMs) and multimodal AI models, supporting models such as Qwen, DeepSeek, Mistral, and Skywork, and is compatible with OpenAI APIs. Two unsafe pickle deserialization vulnerabilities have been identified in the project, tracked as CVE-2026-3059 and CVE-2026-3060.

CVE-2026-3059
SGLangs multimodal generation module is vulnerable to unauthenticated remote code execution through the ZMQ broker, which deserializes untrusted data using pickle.loads() without authentication.

CVE-2026-3060
SGLangs encoder parallel disaggregation system is vulnerable to unauthenticated remote code execution through the disaggregation module, which deserializes untrusted data using pickle.loads() without authentication.

SGLang is vulnerable to CVE-2026-3059 when the multimodal generation system is enabled, and to CVE-2026-3060 when the encoder parallel disaggregation system is enabled. If either condition is met and an attacker knows the TCP port on which the ZMQ broker is listening and can send requests to the server, they can exploit the vulnerability by sending a malicious pickle file to the broker, which will then deserialize it.

CVE-2026-3989
SGLangs replay_request_dump.py contains an insecure pickle.load() without validation and proper deserialization. An attacker can take advantage of this by providing a malicious .pkl file, which will execute the attackers code on the device running the script.

The SGLang project’s replay_request_dump.py script uses pickle.load() without trust validation, allowing for arbitrary code execution if an attacker can control the pickle file contents. This vulnerability has low applicability but high impact, and can be exploited if an attacker can provide a malicious pickle file or write to the crash dump directory, potentially through social engineering or by compromising a directory where crash dump information is automatically saved. The script, intended to replay crash dump information, poses a risk if an attacker can manipulate the input files or directories used by the script.

The use of Pickle is strongly discouraged due to its inherent security risks. Deserializing a pickle file with pickle.loads() can lead to Remote Code Execution (RCE) if an attacker can provide a malicious file. This is because the pickle file format stores not only data but also instructions on how to reconstruct the object, which are executed during deserialization. As a result, an attacker can potentially execute arbitrary Python code.

To mitigate these risks, projects should consider implementing safer serialization formats, such as JSON or XML, or using tools like msgpack to perform more data-driven serialization and deserialization instead of open-ended capabilities such as pickle. This can help prevent RCE attacks and ensure the secure exchange of data.

Impact

An attacker who can send crafted messages to the ZeroMQ interface may trigger unsafe pickle deserialization in SGLang when certain features are enabled, potentially leading to remote code execution. Additionally, an attacker who can provide a malicious pickle file in the context of a crash dump may also exploit CVE-2026-3989. Successful exploitation could allow arbitrary code execution in the context of the SGLang service, potentially leading to host compromise, lateral movement, data exfiltration, or denial-of-service (DoS) attacks. Deployments that expose the affected interface to untrusted networks are at the highest risk of exploitation.

Solution

Users of SGLang should restrict access to the service interfaces and ensure they are not exposed to untrusted networks. Proper network segmentation and access controls should be implemented to prevent unauthorized interaction with the ZeroMQ endpoints. Version 0.5.10 addresses the vulnerabilities.

Acknowledgements

Thanks to the reporter, Igor Stepansky. Thank you to Gregory Bowers for additional research assistance during coordination.This document was written by Christopher Cullen.

Continue reading VU#665416: SGLang (sglang) is vulnerable to code execution attacks via unsafe pickle deserialization→

Overview

Malformed ZIP headers can be used to obfuscate malicious content in ZIP files from antivirus detection tools. Despite the presence of malformed headers, custom extraction software can decompress the ZIP archive, allowing potentially malicious payloads to be recovered after successful antivirus evasion.

After a review of the researcher’s published PoC and further analysis of the case, we have determined that this issue does not meet the necessary criteria to be considered a vulnerability. The originally reported behavior was based on a misunderstanding of native archive-handling capabilities in common operating systems such as Windows and Linux. It was initially believed that native extraction tools could successfully decompress ZIP files with malformed headers, while EDRs and antivirus security tools would fail. After additional testing, we have determined that extraction is not possible through standard archiving tools, and recovering the payload would instead require a custom loader. Accordingly, this technique can be more accurately described as an obfuscation method, as it does not meaningfully violate any implicit or explicit security boundaries.

Description

ZIP archives contain metadata such as compression method, flags, and version information. Antivirus engines typically rely on this metadata to determine how to preprocess files before scanning. If an attacker modifies the compression-method header field, antivirus software may fail to properly decompress the file and will, therefore, be unable to analyze the actual payload.

After antivirus evasion, the payload can be recovered by using a custom loader that ignores the declared Method field and instead decompresses embedded data directly. This allows an attacker to hide malicious content from antivirus engines while still being able to recover it programmatically.

Notably, standard extraction tools (e.g. 7‑Zip, unzip, bsdtar, Python’s zipfile) trust the declared compression method and attempt decompression but then fail with CRC or “unsupported method” errors. These tools do not extract the payload and do not expose the underlying data.

This vulnerability is similar to VU#968818, CVE-2004-0935 but requires unique unpacking tools to enable any abuse or misuse.

Impact

This ZIP header obfuscation method requires custom tooling to fully recover the concealed malicious content. The impact of this obfuscation technique is limited to systems where other security policies (e.g., running arbitrary unzipping tools) may need to be bypassed to enable such an attack.

Solution

Antivirus and EDR vendors should consider alerting on such behavior to ensure their customers are aware of malformed headers in zip content. Users should not use third-party tools or custom unzip capabilities to allow malicious content to be installed on their systems.

Acknowledgements

Thanks to the reporter, Christopher Aziz. This document was written by Laurie Tyzenhaus.

Continue reading VU#976247: Retraction of "Antivirus and Endpoint Detection and Response Archive Scanning Engines may not properly scan malformed ZIP archives"→

Overview

The Rakuten Viber messaging app for Android V25.7.2.0g and Windows V25.6.0.0-V25.8.1.0, has a flaw in its TLS handshake implementation when using the Cloak proxy configuration. This flaw allows for easy identification of proxy usage, potentially compromising user anonymity.

Description

Rakuten Viber can be configured to use a proxy server. Multiple proxy configurations, including Cloak, are supported. Rakuten Viber in Android V25.7.2.0g and Windows V25.6.0.0–V25.8.1.0 exhibits a flaw in the TLS handshake implementation for Cloak mode. Cloak mode is designed to hide the fact that a proxy or VPN is in use.
However, the Cloak proxy mode has a rigid and easily identified fingerprint, making it trivially identifiable by Deep Packet Inspection (DPI) systems. This allows networks to block Viber traffic, undermining the app’s ability to circumvent censorship and potentially leading to denial of service in certain cases.

Impact

The Cloak-mode proxy traffic fails to hide the use of a proxy. The outgoing data is easily identifiable due to the rigid fingerprint and no longer appears to be normal browser TLS behavior. The user has no indication the proxy is not protecting their data.

Solution

Windows users should upgrade to V27.3.0.0 or later, and Android users should upgrade to V27.2.0.0g or later.
For continued support, Windows users can implement automatic updates for Viber.

Acknowledgements

Thanks to the reporter Oleksii Gaienko, an independent security researcher. This document was written by Laurie Tyzenhaus.

Continue reading VU#772695: A flawed TLS handshake implementation affects Viber Proxy in multiple platforms→

Overview

A command injection vulnerability was identified in the MS-Agent framework that can be triggered through unsanitized prompt-derived input. An attacker can craft untrusted input introduced via a chat prompt or other external content sources, resulting in arbitrary command execution on the target system(s) where the MS-Agent framework is deployed. No patch or vendor statement was obtained during the coordination process.

Description

MS-Agent is a lightweight framework that enables agents to perform autonomous task execution and tool invocation. The MS-Agent framework includes several features, including a Shell tool that enables execution of commands on the target operating system to complete agentic actions.

A vulnerability has been identified that allows unsanitized input to be executed through the Shell tool. This occurs because the software does not sufficiently verify and sanitize content before execution. As a result, an attacker can leverage prompt injection techniques to influence the agent into executing unintended shell commands when interacting with attacker-controlled content.

The Shell tool relies on regular expression–based filtering in the check_safe() method, which is intended to restrict unsafe commands. The implemented default denylist can be bypassed, allowing crafted input to evade validation checks and reach the shell execution layer.

The vulnerability is tracked as:

CVE-2026-2256
Command injection vulnerability in ModelScope’s ms-agent allows an attacker to execute arbitrary operating system commands through crafted prompt-derived input.

This vulnerability may be exploited when the agent is instructed to process or retrieve external content, such as analyzing code, summarizing documents, or performing other tasks that involve interacting with attacker-controlled data. If the retrieved or processed content contains malicious command sequences that bypass the check_safe() validation, the agent may forward those commands to the Shell tool for execution.

The use of a regular expression denylist in the check_safe() method is insufficient to prevent command injection. Denylist-based filtering is inherently fragile and can often be bypassed through encoding, command obfuscation, or alternative shell syntax. In this case, the filtering logic can be circumvented, enabling arbitrary command execution within the execution context of the agent process.

Impact

An attacker who successfully exploits this vulnerability may execute arbitrary operating system commands on the target with the privileges of the MS-Agent process. This may allow modification of system files, lateral movement within the environment, establishment of persistence mechanisms, or exfiltration of sensitive data accessible to the agent.

Solution

No statement was provided by the vendor during coordination efforts. Users should deploy MS-Agent only in environments where ingested content is trusted, validated, or sanitized. Agents with shell execution capabilities should be sandboxed or executed with least-privilege permissions. Additional mitigation strategies include replacing denylist-based filtering with strict allowlists and implementing stronger isolation boundaries for tool execution.

Acknowledgements

Thanks to the reporter, Itamar Yochpaz, for this report. Document written by Christopher Cullen.

Continue reading VU#431821: MS-Agent does not properly sanitize commands sent to its shell tool, allowing for RCE→

Overview

A path traversal vulnerability leading to arbitrary file write exist in PyMuPDF version 1.26.5, within the ‘embedded_get’ function in ‘main.py’. This vulnerability is caused by improper handling of untrusted embedded file metadata, which is used directly as an output path, enabling attackers to write files to arbitrary locations on the local system.

Description

PyMuPDF is a Python interface to the MuPDF document rendering engine, providing capabilities for parsing, rendering, searching, and modifying PDF documents.
The ‘embedded_get’ function in PyMuPDF is responsible for opening the provided PDF along with fetching metadata, such as the file name, if using ‘args.output’ it specifies were the file will be written to on the local system. When ‘args.output’ is not provided, the ‘embedded_get’ function falls back to embedded-file metadata, and opens that value in write-binary mode. Since write-binary mode has no constrictions or safety checks it can write anywhere to the local system.
If the derived output path is not supplied by using ‘args.output’, a crafted PDF can be used to target a location on the local system by using the PDF’s name. When an extracted embedded file using ‘embedded_get’ without specified ‘args.output, the tool can write the extracted content outside the intended directory, potentially to paths on the local system.

Impact

Successful exploitation can result in arbitrary file writing to locations permitted by the executing user. If done under an account with elevated privileges, it may overwrite system files. This can lead to privilege escalation, service disruption, or security bypass. ### Overview
A path traversal vulnerability leading to arbitrary file write exists in PyMuPDF version 1.26.5, within the embedded_get function in __main__.py. This vulnerability is caused by improper handling of untrusted embedded file metadata, which is used directly as an output path, enabling attackers to write files to arbitrary locations on the local system.

Description

PyMuPDF is a Python interface to the MuPDF document rendering engine, providing capabilities for parsing, rendering, searching, and modifying PDF documents.
The embedded_get function in PyMuPDF is responsible for opening the provided PDF along with fetching metadata, such as the file name. If using args.output, it specifies where the file will be written on the local system. When args.output is not provided, the embedded_get function falls back to embedded file metadata and opens that value in write-binary mode. Since write-binary mode has no constrictions nor safety checks, it can write to anywhere on the local system.
If the derived output path is not supplied with args.output, a crafted PDF can be used to target a location on the local system using the name of the PDF. When an embedded file is extracted using embedded_get without specified args.output, the tool can write the extracted content outside the intended directory, potentially to paths on the local system.

Impact

Successful exploitation can result in arbitrary file writing to locations permitted by the executing user. If done under an account with elevated privileges, it may overwrite system files. This can lead to privilege escalation, service disruption, or security bypass.

Solution

PyMuPDF has released version 1.26.7 to address this vulnerability. Affected users are encouraged to update as soon as possible.

Acknowledgements

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

Solution

PyMuPDF has released version 1.26.7 to address this vulnerability. Affected users are encouraged to update as soon as possible.

Acknowledgements

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

CVE-2026-3029
A path traversal and arbitrary file write vulnerability exist in the embedded get function in ‘main.py’ in PyMuPDF version, 1.26.5.

Continue reading VU#504749: PyMuPDF path traversal and arbitrary file write vulnerabilities→

Overview

A prototype pollution vulnerability present in CASL Ability versions 2.4.0 through 6.7.4 is triggered through the rulesToFields() function in the extra module. The program’s library contains a method called setByPath() that does not properly sanitize property names, allowing attackers to add or modify properties on an object’s prototype.

Description

The CASL library provides a robust suite for managing attribute-based access control across various components, services, and queries. Access control is defined with a set of rule conditions. The library provides a set of default values for these conditions.

In JavaScript libraries like CASL, prototypes are template objects that serve as blueprints and inform the properties of their child objects. By exploiting this prototype pollution vulnerability, an attacker can inject arbitrary properties into global object prototypes, thereby affecting all child objects that inherit from them. The issue arises from a flaw in the setByPath() function, a component of the rulesToFields() function in the extra module.

The setByPath() function is intended to safely update only permitted fields; however, it fails to properly sanitize path segments before using them as object property keys. Consequently, special property names such as prototype and constructor are accepted as valid keys, allowing an attacker to modify the properties of object prototypes and constructor classes. Furthermore, the _proto_ special property can be used to traverse the prototype chain and ultimately write to Object.prototype, the root prototype of all objects. By polluting Object.prototype, an attacker can add arbitrary properties to all objects and compromise the prototype chain throughout the Node.js process.

Impact

As Object.prototype is the root prototype that all JavaScript objects inherit from, changes to its properties can be significant, allowing an attacker to execute arbitrary code and potentially leading to a complete system compromise. Additionally, an attacker can bypass intended authorization logic, allowing unauthorized access to sensitive resources. Furthermore, changes to Object.prototype can cause unintended behavior in application code, leading to logic manipulation and potentially allowing an attacker to perform actions that would normally be restricted.

Manipulating properties in Object.prototype can also cause crashes or unexpected behavior if polluted properties do not match expected types in the application code, leading to a denial of service. Overall, the Object.prototype pollution vulnerability poses a significant risk to applications and systems. Because the vulnerability exists in the CASL library, which is used by multiple applications and services, a single exploit can have a ripple effect, compromising multiple systems and potentially leading to a widespread security breach.

Solution

Users of the library should upgrade to version 6.7.5 or later, found at https://github.com/stalniy/casl/tree/master/packages/casl-ability.

Acknowledgements

Thanks to Maor Caplan from the Alma Security for coordinating the disclosure of this vulnerability. This document was written by Ayushi Kriplani and Dr. E. Drennan, CISSP.

Continue reading VU#458422: CASL Ability contains a prototype pollution vulnerability→

Overview

An out-of-bounds memory access vulnerability exists in the uncompressed decoder component of libheif. A maliciously crafted HEIF image can trigger a denial-of-service condition by causing the libheif library to crash or exhibit other unexpected behavior due to an out-of-bounds memory access.

Description

libheif is an open-source library used for decoding and encoding modern image formats, including HEIF (High Efficiency Image File Format) and AVIF (AV1 Image File Format). These formats provide high compression efficiency and are widely used across mobile devices and online platforms.

libheif contains an out-of-bounds iterator access vulnerability in its uncompressed codec. The issue occurs when the decoder processes certain metadata structures within a HEIF file. Specifically, the decoder fails to adequately validate values read from an internal metadata box before performing iterator arithmetic on the underlying data buffer.

As a result, a malformed HEIF file can cause the decoder to read past the end of the input buffer and incorrectly interpret unrelated memory as valid metadata. This invalid memory access may lead to a segmentation fault during image decoding.

The CVE-2025-65586 captures this out-of-bounds checking flaw in libheif’s uncompressed codec that allows a maliciously crafted HEIF file to trigger an out-of-bounds read, resulting in a segmentation fault and denial of service when the file is parsed. The vulnerability was introduced in commit 6190b58f (October 3, 2024). Versions v1.19.0 through Versions 1.20.2 are affected by this vulnerbaility. The versions v1.17.6 and earlier are not affected. The issue was reported to the libheif project and has been fixed in commit f4d9157 (November 5, 2025) and then merged to the version release 1.21.0 at the end of 2025.

Impact

An attacker can exploit this vulnerability by supplying a maliciously crafted HEIF image, causing applications that use libheif to crash. Based on current analysis, exploitation is limited to denial-of-service conditions.

Potential impacts include

• Unexpected termination of applications that decode HEIF images
• Crashes in systems that automatically generate previews or thumbnails
• Disruption of services that process untrusted HEIF content (e.g., browsers, email clients, photo management tools)

There is no evidence at this time that this vulnerability can be used to achieve memory disclosure or arbitrary code execution.

Discovery

The vulnerability was discovered through coverage-guided fuzzing using AddressSanitizer-instrumented builds of libheif. The issue was reproducible across standard Linux development environments.

Solution

Software vendors and developers using the libheif library are strongly encouraged to update to version 1.21.0 or later, which includes the fix for this vulnerability. End users should apply available software updates to ensure they are running a version of libheif that addresses this issue.

Acknowledgements

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

Continue reading VU#481830: Libheif uncompressed codec lacks bounds check leading to application crash→

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.

Continue reading VU#102648: Code injection vulnerability in binary-parser library→

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.

Continue reading VU#458022: Open5GS WebUI uses a hard-coded secrets including JSON Web Token signing key→