CVE-2026-0622 — Open5GS WebUI Hard-coded JWT Signing Key

• CVE: CVE-2026-0622
• Title: Open5GS WebUI uses a hard-coded JWT signing key
• Severity: High (practical impact)
• CVSS: Not yet published in official database
• Exploitability: Easy if vulnerable configuration exists
• Exploit availability: Public discussions and test references exist, but no widely published exploit code

What the Vulnerability Is

Open5GS is an open-source 5G core implementation. It includes a web-based management interface (“WebUI”) built on Node.js and Next.js to administer configuration and subscriber data.

In this WebUI, the system issues and verifies JSON Web Tokens (JWT) for authentication. These tokens are signed using a secret key stored in the environment (e.g., JWT_SECRET_KEY). If that variable isn’t explicitly set by the operator, the code falls back to a default static value — literally the string “change-me”.

That default is predictable. Since attackers can easily guess it, they can produce tokens that the WebUI will accept as valid.

Why This Matters

In simple terms:

• If a deployment has not changed the default secret, an attacker who can connect to the WebUI service can create a token that looks legitimate.
• That token can be crafted to appear to be from an authenticated, authorized administrative user.
• With that token, the attacker can call protected management APIs on the WebUI and perform sensitive actions.

Potential consequences include:

• Unauthorized administrative access to the WebUI.
• Reading or changing subscriber data.
• Modifying system configuration.
• Bypassing any login/password protections entirely.

Because the fall-back secret is public and predictable, this is a serious security weakness in default deployments.

How It Could Be Exploited

Here’s the high-level pattern of how an attacker might misuse it:

1. The attacker locates a reachable Open5GS WebUI endpoint (HTTP/S).
2. They assume (or test and confirm) that the installation is using default settings and has not set a custom JWT secret.
3. Knowing the fallback key (change-me), they craft a JWT that carries elevated privileges (e.g., admin role).
4. They send that token in a request to the API endpoints (for example, those under /api/db/*) and the WebUI accepts it as authentic.
5. The attacker issues configuration changes or extracts sensitive data.

This sequence does not require knowing any real credentials, and there is no need for interactive user login because the token authentication is broken.

Exploit Availability

• There is no official exploit code released tied to this CVE at the time of writing, but the nature of the vulnerability (predictable secret) makes a proof-of-concept trivial for anyone familiar with JWT.
• Public security discussion threads show people talking about how to generate tokens for testing, but crafting a token is still something offensive security professionals should control responsibly.

How to Detect Vulnerable or Exploited Instances

1. Environment Configuration Checks

• Look at the environment where the WebUI runs.
• If the WebUI process/container does not have JWT_SECRET_KEY set (or it equals “change-me”), it’s vulnerable.
• Review deployment manifests, environment files, container configs, and start-up logs.

2. Token Inspection

• Analyse incoming JWT tokens to the WebUI.
• A defensive check: try validating tokens against the known fallback secret (change-me) in a controlled environment. Tokens that validate with that key indicate a vulnerable or misconfigured system.

3. Unusual API Activity

Monitor web access logs for:

• Requests to admin API endpoints like /api/db/* from sources that shouldn’t be accessing them.
• POST/PUT/DELETE requests that modify configuration or data without a normal authenticated session.
• JWT usage patterns that don’t match expected login flows.

These are signs of possible token forgery or misuse.

Defensive Detection Rules

Here are example logical rules you can adapt to your SIEM:

Web Access / API Monitoring

Detect suspicious API calls:
HTTP_METHOD in (POST, PUT, DELETE) AND URL_PATH starts with "/api/db/"
AND CLIENT_IP not in expected trusted admin IP list

JWT Validation Anomaly

Extract JWT from Authorization: Bearer header
Attempt defensive validation with default secret ("change-me")
If validation succeeds AND live environment should never use default -> alert

These rules are meant to trigger alerts, not to block traffic outright.

Logs & Systems to Monitor

To cover detection effectively, prioritize:

• Web server access logs (nginx, Apache, reverse proxies)
• Application logs from the WebUI service
• Container logs (Docker, Kubernetes)
• Network flow logs
• Any MFA/audit logs tied to administrative sessions

How to Prevent / Mitigate

Immediate Configuration Fix

Before the patch is applied:

• Set a strong, unique secret for both:
  • SECRET_KEY
  • JWT_SECRET_KEY
• Use long, random values (crypto random, 32+ characters)
• Treat secrets like credentials — store them securely (vault, secret manager, sealed Kubernetes secrets).

Without doing this, the WebUI remains insecure.

Network Hardening

• Limit access to the WebUI to trusted networks only.
• Do not expose it to public internet.
• Use VPN or secure gateways if remote access is required.
• Consider placing WAF in front to throttle unusual API access patterns.

Patch / Upgrade

The official upstream fix changes how secrets are managed so hard-coded values are no longer used. It adds proper environment handling so each deployment has its own unique secure secret.

Official Patch / Fix Link:
🔗 https://github.com/open5gs/open5gs/pull/857

Apply that fix or a vendor-released build that includes it as soon as possible. Upgrading to a patched version should be treated as a priority.

Post-Incident Response Checklist

If you suspect exploitation:

1. Isolate the affected WebUI host or service.
2. Collect logs across web access, container, and application layers.
3. Rotate secrets immediately (strong new values).
4. Invalidate existing tokens — restart the WebUI so old JWTs are no longer accepted.
5. Audit changes made via WebUI since last clean state.
6. Restore from backups if unauthorized changes are confirmed.
7. Re-deploy behind hardened network controls and apply the official fix.

Final Takeaway

• Confirm your WebUI is not using the default JWT secret (change-me).
• Set strong, unique environment secrets.
• Apply the official fix/upgrade (link above).
• Monitor API access for token anomalies and unusual admin activity.
• Restrict network access to the WebUI.