CVE-2026-0622: Open 5GS WebUI Information Disclosure Flaw

CVE-2026-0622 Overview

Open 5GS WebUI contains a hardcoded credentials vulnerability where the application uses a hard-coded JWT signing key (change-me) whenever the environment variable JWT_SECRET_KEY is unset. This insecure default configuration allows attackers with network access to forge authentication tokens and potentially bypass authentication controls in 5G core network management interfaces.

Critical Impact

Attackers can exploit the default JWT signing key to forge authentication tokens, potentially gaining unauthorized access to the Open 5GS WebUI management interface and compromising 5G network configurations.

Affected Products

• Open 5GS WebUI (versions with unset JWT_SECRET_KEY)

Discovery Timeline

• January 20, 2026 - CVE CVE-2026-0622 published to NVD
• January 21, 2026 - Last updated in NVD database

Technical Details for CVE-2026-0622

Vulnerability Analysis

This vulnerability represents a classic insecure default configuration issue in the Open 5GS WebUI component. The application uses JSON Web Tokens (JWT) for authentication and session management. When administrators deploy the WebUI without explicitly setting the JWT_SECRET_KEY environment variable, the application falls back to using a predictable, hard-coded value of change-me as the signing key.

JWT authentication relies on the secrecy of the signing key to ensure token integrity. With a known signing key, any attacker can craft valid JWT tokens with arbitrary claims, including elevated privileges or impersonated user identities. This effectively bypasses the entire authentication mechanism, as the server will accept any properly signed token regardless of whether it was legitimately issued.

The network-accessible nature of this vulnerability means that remote attackers who can reach the WebUI interface can exploit this flaw without any prior authentication. The impact includes potential unauthorized read and write access to 5G network configurations, subscriber data, and management functions.

Root Cause

The root cause of this vulnerability is the use of a hardcoded default value for a cryptographic secret. The Open 5GS WebUI was designed to allow configuration of the JWT signing key via the JWT_SECRET_KEY environment variable, but the fallback behavior of using a predictable default value (change-me) creates an insecure default configuration. This design decision prioritizes ease of initial deployment over security, leaving systems vulnerable when administrators fail to explicitly configure a secure secret.

Attack Vector

The attack leverages the network-accessible WebUI interface. An attacker with knowledge of the default JWT signing key can:

1. Identify Open 5GS WebUI deployments using the default configuration
2. Craft a malicious JWT token signed with the known key change-me
3. Include arbitrary claims in the token payload (e.g., admin privileges)
4. Submit requests to the WebUI API with the forged token
5. Gain unauthorized access to management functions

The vulnerability requires no user interaction and can be exploited with low complexity. The attacker does not need any prior authentication or privileges on the target system.

For technical details on the vulnerability mechanism and discussion, see GitHub Issue #2264, GitHub Issue #856, and the CERT Vulnerability Advisory #458022.

Detection Methods for CVE-2026-0622

Indicators of Compromise

• Authentication logs showing successful logins from unexpected IP addresses or user accounts
• JWT tokens in HTTP headers containing suspicious or unexpected claims
• Unusual administrative actions in WebUI audit logs without corresponding legitimate user activity
• Network traffic analysis revealing JWT tokens signed with the default change-me key

Detection Strategies

• Audit Open 5GS deployments to verify the JWT_SECRET_KEY environment variable is properly configured with a strong, unique secret
• Implement monitoring for authentication anomalies such as logins from unusual geolocations or at unusual times
• Deploy network intrusion detection rules to identify requests containing JWTs signed with the known default key
• Review WebUI configuration files and container environment settings during security assessments

Monitoring Recommendations

• Enable comprehensive logging for all WebUI authentication events and administrative actions
• Configure alerts for failed authentication attempts followed by successful access
• Monitor for configuration changes to 5G network parameters that could indicate unauthorized access
• Implement session monitoring to detect token reuse or tokens with anomalous lifetimes

How to Mitigate CVE-2026-0622

Immediate Actions Required

• Set the JWT_SECRET_KEY environment variable to a strong, randomly generated secret (minimum 32 characters recommended)
• Rotate the JWT signing key and invalidate all existing sessions if the default key may have been exposed
• Review WebUI access logs for signs of unauthorized access during the exposure period
• Restrict network access to the Open 5GS WebUI to trusted management networks only

Patch Information

The fix involves ensuring that a secure, unique JWT signing key is configured before the WebUI can operate. See GitHub Pull Request #857 for the related code changes. Administrators should update to patched versions and verify that their deployment configurations include a properly set JWT_SECRET_KEY environment variable.

Additional information is available in the CERT Vulnerability Advisory #458022.

Workarounds

• Set a strong, unique value for the JWT_SECRET_KEY environment variable in all deployment environments
• Place the Open 5GS WebUI behind a VPN or network access control to limit exposure to trusted networks
• Implement additional authentication layers such as client certificates or IP-based access restrictions
• Disable the WebUI entirely if it is not required for operations, relying on CLI or API management instead

# Configuration example
# Set a strong JWT secret key for Open 5GS WebUI
# Generate a secure random key:
export JWT_SECRET_KEY=$(openssl rand -base64 32)

# Or set explicitly in your deployment configuration:
export JWT_SECRET_KEY="your-strong-unique-secret-key-here"

# For Docker deployments, include in docker-compose.yml:
# environment:
#   - JWT_SECRET_KEY=your-strong-unique-secret-key-here