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
Other Information
| CVE IDs: | |
| Date Public: | 2026-01-20 |
| Date First Published: | 2026-01-20 |
| Date Last Updated: | 2026-01-20 17:41 UTC |
| Document Revision: | 1 |
