Cyber Resilience

CVE-2026-0622

Exposed Creds in Open5Gs ≤ 2.7.6

Published
20 January 2026
Modified
03 February 2026
Patch / advisory
CVSS Score v3.1 6.5
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
EPSS Score 0.0041 33th percentile
Risk Priority 35 floored blend · peak EPSS

Summary

CVE-2026-0622 is a medium-severity Use of Hard-coded Credentials (CWE-798) vulnerability in Open5Gs Open5Gs. Its CVSS base score is 6.5 (Medium).

Operationally, exploitation aligns with the MITRE ATT&CK technique Default Accounts (T1078.001); ranked at the 33th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to IA-5 (Authenticator Management) and SC-12 (Cryptographic Key Establishment and Management) — see the control section below for these in your framework.

OWASP Top 10 for Web (2025)

EU & UK References

Vulnerability Data

Open 5GS WebUI uses a hard-coded JWT signing key (change-me) whenever the environment variable JWT_SECRET_KEY is unset

CWE(s)

Related Threats

MITRE ATT&CK Enterprise TechniquesAI

T1078.001 Default Accounts Stealth
Adversaries may obtain and abuse credentials of a default account as a means of gaining Initial Access, Persistence, Privilege Escalation, or Defense Evasion.
Why these techniques?

Hard-coded default JWT signing key directly enables use of default credentials for authentication bypass.

Confidence: HIGH · MITRE ATT&CK Enterprise v19.0

CVEs Like This One

CVE-2025-29339Same product: Open5Gs Open5Gs
CVE-2025-44951Same product: Open5Gs Open5Gs
CVE-2023-37004Same product: Open5Gs Open5Gs
CVE-2026-8120Same product: Open5Gs Open5Gs
CVE-2025-7485Same product: Open5Gs Open5Gs
CVE-2023-37005Same product: Open5Gs Open5Gs
CVE-2023-37014Same product: Open5Gs Open5Gs
CVE-2024-34235Same product: Open5Gs Open5Gs
CVE-2024-57519Same product: Open5Gs Open5Gs
CVE-2025-41067Same product: Open5Gs Open5Gs

Affected Assets

open5gs
open5gs
≤ 2.7.6

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)
  • SC-12 Cryptographic Key Establishment and Management
  • IA-5 Authenticator Management
  • CM-6 Configuration Settings
Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)

Validate
Prove the fix (OWASP ASVS)

Mitigating Controls (NIST 800-53 r5) AI

prevent

Directly requires proper cryptographic key establishment and management, eliminating reliance on any hard-coded JWT signing key.

prevent

Mandates secure authenticator (secret) management and prohibits hard-coded or default credentials such as the JWT signing key.

prevent

Enforces configuration settings that require JWT_SECRET_KEY to be explicitly supplied rather than falling back to the hard-coded default.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.AA-01 partial match
prevents

PR.AA-01's credential/key-management processes can reduce the incentive to embed secrets but do not address or detect hard-coded values in source code, so the weakness remains fully possible.

PR.AA-02 none match
prevents

PR.AA-02 addresses human identity proofing and per-person credential issuance at enrollment; it has no bearing on whether developers embed static credentials in software.

PR.DS-01 none match
prevents

PR.DS-01 addresses encryption and integrity of stored data but never touches credential or key management practices, so it neither prevents hard-coded credentials nor removes any of their risk.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

prevents

Education on secure configuration practices discourages technical staff from embedding or relying on hard-coded credentials in systems and applications.

mitigates

Secure key-generation, distribution and storage procedures reduce the likelihood that hard-coded or default cryptographic keys will be introduced or left unprotected.

prevents

Explicit prohibition of hard-coded passwords and unauthenticated external services stops credentials from being embedded directly in source code.

prevents

Contractual requirements for secure coding practices and evidence of testing make it less likely that hard-coded credentials will be introduced or remain undetected in delivered code.

none

Requiring independent oversight and timely disabling of non-human identities makes it harder for hard-coded or long-lived credentials to remain exploitable.

none

Mandating immediate replacement of vendor-supplied default credentials eliminates the use of hard-coded or factory passwords that attackers can trivially obtain from documentation or firmware.

References