CVE-2026-8291
Denial of Service in Open5GS NRF Component
Publication date: 2026-05-11
Last updated on: 2026-05-11
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| open5gs | open5gs | to 2.7.7 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-404 | The product does not release or incorrectly releases a resource before it is made available for re-use. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-8291 is a denial-of-service (DoS) vulnerability in Open5GS, specifically affecting the Network Repository Function (NRF) component. The vulnerability arises when the NRF processes an oversized NFProfile payload or an excessive number of NF instances in discovery responses. This causes the NRF to exhaust its fixed-size resource pools, triggering assertion failures that crash the NRF process. The attack can be carried out remotely by sending crafted requests with large payloads or responses, leading to a crash of the NRF and disruption of its services.
How can this vulnerability impact me? :
This vulnerability can cause the NRF component of Open5GS to crash, resulting in a denial of service. When the NRF crashes, it terminates all ongoing Service-Based Architecture (SBA) sessions for legitimate peers, disrupting the core network functions of LTE/NR networks that rely on Open5GS. This can lead to network outages or degraded service availability, impacting users and services dependent on the affected network.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability causes the Open5GS Network Repository Function (NRF) to crash due to resource exhaustion when processing oversized NFProfile payloads or discovery responses containing excessive NF instances.
Detection can focus on monitoring NRF logs for crashes or assertion failures, especially messages related to pool exhaustion or SIGABRT signals.
Network detection could involve capturing and analyzing inter-PLMN discovery requests and responses to identify unusually large NFProfile payloads or SearchResult entries exceeding normal thresholds.
- Check NRF process status and logs for crashes or exit code 139 (SIGABRT).
- Use system commands like `journalctl -u open5gs-nrf` or `tail -f /var/log/open5gs/nrf.log` to monitor NRF logs for assertion failures or pool exhaustion warnings.
- Capture network traffic on relevant ports (e.g., using `tcpdump` or `wireshark`) to inspect NFProfile payload sizes and discovery response contents.
- Example tcpdump command: `tcpdump -i <interface> port <NRF_port> -w nrf_traffic.pcap`
- Analyze captured traffic for unusually large JSON payloads in NFProfile or discovery responses.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves updating Open5GS to a version that includes the fix for CVE-2026-8291 once it is accepted and released.
The fix replaces the assertion failure with a graceful handling mechanism that caps and truncates oversized NFProfile payloads, preventing crashes.
Until the fix is applied, consider limiting exposure by restricting access to the NRF service from untrusted or external sources to reduce the risk of malicious oversized requests.
Monitor NRF logs for signs of exploitation attempts and prepare to restart the NRF service if it crashes.
- Apply the patch or upgrade Open5GS to a version including the fix described in the pull request.
- Restrict network access to the NRF component to trusted clients only.
- Implement monitoring and alerting on NRF crashes or abnormal behavior.