CVE-2026-8291: Open5GS Denial of Service Vulnerability

CVE-2026-8291 Overview

CVE-2026-8291 is a denial of service vulnerability in Open5GS through version 2.7.7. The flaw resides in the ogs_nnrf_nfm_handle_nf_profile function within lib/sbi/nnrf-handler.c, part of the Network Repository Function (NRF) component. An authenticated remote attacker can manipulate input to trigger the issue, disrupting service availability of the 5G core network function. The weakness is categorized under [CWE-404] Improper Resource Shutdown or Release. A public exploit has been disclosed, and a pull request to remediate the issue is pending acceptance upstream.

Critical Impact

Remote attackers with low privileges can disrupt availability of the Open5GS NRF, impairing service discovery across the 5G Service-Based Architecture (SBA).

Affected Products

• Open5GS up to and including version 2.7.7
• Component: Network Repository Function (NRF)
• File: lib/sbi/nnrf-handler.c

Discovery Timeline

• 2026-05-11 - CVE-2026-8291 published to NVD
• 2026-05-14 - Last updated in NVD database

Technical Details for CVE-2026-8291

Vulnerability Analysis

The vulnerability resides in ogs_nnrf_nfm_handle_nf_profile, the handler responsible for processing NF (Network Function) profile data received by the NRF. The NRF is a central control-plane component in 5G core deployments, providing service registration and discovery for other network functions via the Service-Based Interface (SBI). Improper handling of resources during profile parsing causes the function to fail in a manner that disrupts availability. An attacker reachable over the SBI interface can submit crafted requests that exercise the flawed path, leading to denial of service of the NRF process.

Root Cause

The root cause is mapped to [CWE-404] Improper Resource Shutdown or Release. The handler does not correctly release or manage resources when processing certain NF profile inputs, resulting in conditions that interrupt normal operation. Refer to the upstream discussion in GitHub Open5GS Issue #4456 and the proposed fix in GitHub Open5GS Pull Request #4534 for technical specifics.

Attack Vector

Exploitation occurs over the network against the NRF's SBI endpoint. The attacker requires low privileges and no user interaction. Because the NRF brokers discovery for other 5G network functions, an outage propagates into broader service-discovery failures across the core. A public exploit is referenced in the VulDB #362588 entry. No verified proof-of-concept code is reproduced here; consult the upstream issue tracker for technical details.

Detection Methods for CVE-2026-8291

Indicators of Compromise

• Unexpected termination, restarts, or hangs of the Open5GS nrf process
• Surges of malformed or anomalous NF profile registration requests on the SBI interface
• Loss of service discovery responses observed by AMF, SMF, UPF, and other consumer NFs

Detection Strategies

• Monitor NRF process health and restart counts via container or systemd telemetry
• Inspect SBI HTTP/2 traffic for malformed NF profile payloads targeting /nnrf-nfm/v1/nf-instances
• Correlate NRF crashes with preceding SBI requests using packet capture and structured logs

Monitoring Recommendations

• Alert on repeated 5xx responses or connection resets from the NRF
• Track cascading registration failures across downstream NFs that depend on the NRF
• Forward Open5GS logs to a centralized analytics platform for retention and correlation

How to Mitigate CVE-2026-8291

Immediate Actions Required

• Restrict SBI access to trusted network functions using network segmentation and mTLS-authenticated peers
• Rate-limit and validate incoming NF profile registration traffic at an ingress proxy
• Track the upstream GitHub Open5GS Pull Request #4534 and apply the patch once merged

Patch Information

At the time of publication, the fix is pending acceptance upstream in GitHub Open5GS Pull Request #4534. Operators running Open5GS 2.7.7 or earlier should monitor the Open5GS project repository for a tagged release containing the fix and upgrade promptly.

Workarounds

• Place the NRF behind a service mesh or API gateway that enforces schema validation on NF profile submissions
• Limit NRF reachability to the internal 5G core control plane only, denying all external network access
• Deploy redundant NRF instances to reduce single-point-of-failure impact during exploitation attempts

# Configuration example: restrict NRF SBI exposure with iptables
iptables -A INPUT -p tcp --dport 7777 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 7777 -j DROP