Which versions of Open5GS NRF are affected by CVE-2025-41068?

Open5GS 5G core deployments through version 2.7.6 are vulnerable to a denial-of-service attack that can disable the Network Repository Function (NRF), disrupting the registration and discovery of…

How to fix or mitigate CVE-2025-41068?

Within 24 hours, identify all Open5GS 5G core deployments through version 2.7.6 and restrict network access to the Service-Based Interface (SBI) to only trusted network functions and network segments; enable logging and monitoring for invalid NF type registrations and NRF crashes. Within 7 days, implement network segmentation to isolate the NRF from untrusted networks, and consider rate limiting or input validation at the NRF if feasible; review and harden access controls for all NFs. Within 30 days, engage the Open5GS vendor or community for patch availability and timeline, and plan to upgrade to a fixed version as soon as it is released; in the interim, continue monitoring and consider deploying a redundant NRF instance to mitigate single points of failure. Note: No vendor-released patch identified at time of analysis.

Open5GS NRF CVE-2025-41068

Q: What is the CVSS score of CVE-2025-41068?

CVE-2025-41068 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

HIGH

Reachable Assertion (CWE-617)

2025-10-27 cve-coordination@incibe.es

Denial Of Service Open5gs

8.7

CVSS 4.0 · Vendor: incibe

Severity by source

Vendor (incibe) PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.5 HIGH

Remote low-complexity unauthenticated reachable assertion crashing the NRF process; availability-only impact, no confidentiality or integrity, scope unchanged.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L

Primary rating from Vendor (incibe).

CVSS VectorVendor: incibe

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Oct 08, 2026 - 11:48 vuln.today

CVE Published

Oct 27, 2025 - 13:15 cve.org

HIGH 8.7

DescriptionCVE.org

Reachable Assertion vulnerability in Open5GS up to version 2.7.6 allows attackers with connectivity to the NRF to cause a denial of service. This is achieved by sending the creation of an NF with an invalid type via SBI and then requesting its data. The NRF executes a check that crashes the process, leaving the discovery service unresponsive.

AnalysisAI

Denial of service in the Open5GS 5G core Network Repository Function (NRF) lets remote, unauthenticated attackers who can reach the Service-Based Interface (SBI) crash the discovery service by registering an NF instance with an invalid NF type and then requesting that instance's data, which trips a reachable assertion (CWE-617) and aborts the process. Every Open5GS build through 2.7.6 is affected per the wildcard CPE, and the failure of the NRF takes down NF registration and discovery for the whole core, so new network functions cannot join and existing ones cannot be located. Risk signals are moderate rather than critical: EPSS is 0.36% (27th percentile), there is no CISA KEV entry, and no public exploit code has been identified at time of analysis; the primary limiter is reachability, since the AV:N vector overstates the practical requirement that the attacker sit inside the core network or control a rogue/compromised NF.

Technical ContextAI

Open5GS is an open-source implementation of the 5G core (and 4G EPC). The NRF (open5gs-nrfd) is the service registry of the 5G Service-Based Architecture: it exposes the Nnrf_NFManagement service over the SBI, implemented as HTTP/2 with JSON payloads per 3GPP TS 29.510, where NF instances are created and updated via /nnrf-nfm/v1/nf-instances/{nfInstanceID} and carry an nfType field drawn from the standardised set of network function types (AMF, SMF, UPF, AUSF, UDM, etc.). This CVE is CWE-617 (Reachable Assertion): the NRF accepts and stores an NF registration whose nfType is invalid, then, when that instance's data is subsequently requested, hits an internal ogs_assert()-style sanity check that calls abort(), terminating the single NRF process. Because the NRF is a shared, stateful singleton in the control plane, a single malformed registration/read sequence produces an availability failure that propagates to every consumer of NF discovery and registration, while other NFs already running generally continue to operate (consistent with VA:H / SA:L in the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). The CPE cpe:2.3:a:open5gs:open5gs:*:*:*:*:*:*:*:* marks all released versions as in scope, with 2.7.6 the last confirmed-affected release named in the description; the INCIBE notice groups this with other issues in Open5GS, and the referenced upstream v2.7.6 release notes are the only version-specific patch reference supplied.

RemediationAI

The supplied data does not name an exact fixed version, so do not assume 2.7.6 is patched: track the INCIBE-CERT advisory (https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-newplanes-open5gs) and the Open5GS release notes (https://open5gs.org/open5gs/release/2025/07/19/release-v2.7.6.html), and upgrade to the first upstream release confirmed to fix the invalid-nfType assertion path (patch status: vendor advisory referenced, exact fixed version not independently confirmed from available data). Because the root cause is a hard assertion rather than a memory-safety bug, there is no configuration switch that removes the crash; the effective controls are exposure reduction and availability hardening. First, treat the SBI as control-plane infrastructure: firewall/segment it so the NRF is reachable only from trusted NFs, and never expose Nnrf endpoints to untrusted or internet-routed networks - trade-off is that legitimate roaming/interconnect and multi-vendor interop NFs must be explicitly allow-listed, which adds operational overhead. Second, enforce transport security and NF-level authorization on the SBI (TLS with mutual certificate authentication and OAuth2 access tokens per 3GPP), which raises the bar for a rogue NF but does not stop a legitimately authorized NF from sending the malformed nfType. Third, monitor NRF logs for registration attempts with out-of-range or non-standard nfType values and for sudden SIGABRT/restart events, and alert on them. Fourth, run open5gs-nrfd under a supervisor with automatic restart (systemd Restart=always, or a Kubernetes liveness probe) so a crash becomes a short registration/discovery outage instead of an indefinite one - trade-off is that an attacker can induce a restart loop, causing repeated brief discovery flaps. Finally, since these are network-reachable availability bugs with no public exploit code identified, prioritize by actual NRF reachability rather than by the raw CVSS score.