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

Open5GS releases up to and including 2.7.6 contain a flaw in the Network Repository Function (NRF) that lets a crafted signaling request from a network-reachable source terminate the NRF process,…

How to fix or mitigate CVE-2025-41067?

Within 24 hours, confirm which Open5GS deployments are running version 2.7.6 or earlier and inventory every network path that can reach the NRF Service Based Interface; where feasible, tighten firewall and segmentation rules so only authorised network functions on the core/signaling segment can send SBI requests to the NRF, and enable process supervision (systemd restart or equivalent watchdog) plus alerting so an NRF crash is detected and recovered immediately. Within 7 days, implement monitoring and alerting on NRF SBI traffic for delete operations targeting the NRF's own nfInstanceID, place the NRF behind an internal API gateway or proxy that can filter and rate-limit anomalous SBI requests, verify high-availability or redundant NRF placement so a single process abort does not remove discovery entirely, and engage the Open5GS maintainers and your vendor or integrator to obtain a fixed release or backport for versions after 2.7.6. Within 30 days, plan and execute an upgrade to the first Open5GS release that contains the fix once it is published, re-validate segmentation controls between the SBI and any external or untrusted networks, add detection signatures for this request pattern to core-network monitoring, and rerun the exposure assessment to confirm no affected 2.7.6-or-earlier instances remain.

Open5GS NRF CVE-2025-41067

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

CVE-2025-41067 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

8.6 HIGH

Unauthenticated low-complexity SBI request (AV:N/AC:L/PR:N); S:C because crashing the NRF also denies discovery to other network functions; impact is availability-only (A:H), no C/I.

3.1 AV:N/AC:L/PR:N/UI:N/S:C/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. An SBI request that deletes the NRF's own registry causes a check that ends up crashing the NRF process and renders the discovery service unavailable.

AnalysisAI

An unauthenticated SBI request sent to the Open5GS NRF (Network Repository Function) in releases up to 2.7.6 can crash the process and take down 5G service discovery by deleting the NRF's own NF registry entry, triggering a reachable assertion (CWE-617). Exploitation requires network reachability to the NRF's Service Based Interface and the ability to issue a delete against the NRF's own nfInstanceID; per the supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) no authentication is required, though in a properly segmented 5G core the SBI is an internal control-plane network, so realistic access implies a foothold on the core/signaling segment rather than arbitrary internet exposure. Impact is availability-only - the NRF process aborts and NF discovery becomes unavailable, with no confidentiality or integrity effect; there is no public exploit identified at time of analysis, no CISA KEV listing, and EPSS is low at 0.43% (35th percentile), and service can be restored by restarting the NRF.

Technical ContextAI

Open5GS is an open-source implementation of the 5G Core and EPC. Its 5G Service Based Architecture exposes control-plane functions over a Service Based Interface (SBI) that speaks HTTP/2 with JSON payloads; the NRF acts as the service registry, maintaining NF profiles and answering discovery queries from other NFs (AMF, SMF, UPF, AUSF, UDM and so on). This issue is rooted in CWE-617 (Reachable Assertion): when an SBI request is processed that deletes the NRF's own registry entry, an internal invariant check fails and the assertion handler terminates the process rather than rejecting or handling the request gracefully. The CPE cpe:2.3:a:open5gs:open5gs:*:*:*:*:*:*:*:* indicates the flaw is tracked against the Open5GS product line as a whole through version 2.7.6, i.e., the NRF component shipped within those releases. Because the failure mode is a hard process abort rather than degraded-but-functional behavior, any NF that depends on the NRF for discovery may fail to locate its peers until the NRF is restarted, which is the mechanism that turns a single malformed-but-legitimate delete request into a control-plane availability event.

RemediationAI

Patch available per vendor advisory; upgrade Open5GS past the 2.7.6 release line to the current maintained release (the fixed version is not explicitly stated in the supplied data, so verify the correction against the upstream release notes at https://open5gs.org/open5gs/release/2025/07/19/release-v2.7.6.html and the INCIBE advisory at https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-newplanes-open5gs before relying on a specific build). Until an upgrade is validated, apply layered compensating controls: keep the NRF SBI strictly on the internal control-plane network and block it at the perimeter so only known NF peers (AMF/SMF/UPF/AUSF/UDM, SCP) can reach it, since the attack is only reachable from that segment but the trade-off is that overly tight ACLs break roaming and inter-PLMN discovery if peer addresses are not maintained; enforce HTTP/2 TLS with mutual authentication and NF-side authorization/allow-listing so unrecognized clients cannot submit registry operations, accepting the added certificate and key-management overhead; front the NRF with an SCP or an API gateway rule set that rejects DELETE operations against an nfInstanceID equal to the NRF's own instance (or rejects self-referential instance operations generally), noting that legitimate NF deregistration flows must still be permitted; and run the NRF under a supervisor with automatic restart and health checks plus alerting on abnormal process exits, which restores discovery quickly but does not prevent the crash. Monitor SBI logs for delete requests targeting the NRF's own instance as a detection and forensics signal.