CVE-2026-10117: Open5GS DoS Vulnerability

CVE-2026-10117 Overview

CVE-2026-10117 is a denial of service vulnerability in Open5GS versions up to 2.7.7. The flaw resides in the ogs_pool_id_calloc function within the /lib/sbi/nghttp2-server.c library component, which handles Service Based Interface (SBI) HTTP/2 server operations. An authenticated remote attacker can manipulate input to this function to trigger a denial of service condition. The weakness is classified as improper resource shutdown or release [CWE-404]. Public exploit code is referenced in the VulDB advisory, increasing the likelihood of opportunistic exploitation against exposed Open5GS deployments used in 5G core network testing and research environments.

Critical Impact

Remote attackers with low privileges can disrupt Open5GS Service Based Interface availability, impacting 5G core network signaling functions.

Affected Products

• Open5GS versions up to and including 2.7.7
• Open5GS SBI library component (/lib/sbi/nghttp2-server.c)
• 5G core network deployments using vulnerable Open5GS builds

Discovery Timeline

• 2026-05-30 - CVE-2026-10117 published to NVD
• 2026-06-01 - Last updated in NVD database

Technical Details for CVE-2026-10117

Vulnerability Analysis

The vulnerability affects Open5GS, an open-source implementation of 5G Core and EPC. The defect sits in ogs_pool_id_calloc, a memory pool allocation routine invoked by the nghttp2-based Service Based Interface server. Open5GS uses fixed-size object pools to manage HTTP/2 session and stream identifiers. When an attacker triggers specific request patterns against the SBI endpoint, the pool allocator fails to properly release identifiers, leading to resource exhaustion. The function eventually returns failure, and the affected network function process degrades or terminates. Because SBI is the communication backbone between 5G Network Functions such as AMF, SMF, and UPF, loss of service propagates across the core. The flaw is reachable over the network and requires only low-level privileges on the SBI interface.

Root Cause

The root cause is improper resource shutdown or release [CWE-404] in the pool identifier allocation path. Identifiers consumed by HTTP/2 sessions are not reliably returned to the pool when sessions terminate abnormally, depleting the available pool over time.

Attack Vector

An attacker reaches the vulnerable code path by sending crafted HTTP/2 requests to the Open5GS SBI listener. Repeated requests exhaust the identifier pool, after which subsequent legitimate requests fail. The attack does not require user interaction.

No verified proof-of-concept code is reproduced here. Technical details are available in the referenced GitHub Issue #4474 and VulDB Vulnerability #367295.

Detection Methods for CVE-2026-10117

Indicators of Compromise

• Repeated HTTP/2 connection attempts to Open5GS SBI ports from a single source followed by service degradation
• Open5GS log entries showing ogs_pool_id_calloc allocation failures or pool exhaustion warnings
• Unexpected restarts or crashes of Open5GS network function processes (AMF, SMF, NRF, AUSF)
• Sustained increase in HTTP/2 stream creation rate against SBI endpoints

Detection Strategies

• Monitor Open5GS process logs for pool allocation errors emitted by the SBI library
• Baseline HTTP/2 request rates on SBI interfaces and alert on deviations
• Correlate network function restarts with inbound SBI traffic spikes

Monitoring Recommendations

• Enable verbose logging on Open5GS SBI components to capture pool state transitions
• Collect process metrics (memory, file descriptors, restart counts) for each Open5GS network function
• Restrict SBI interface exposure to trusted management networks and log all inbound HTTP/2 sessions

How to Mitigate CVE-2026-10117

Immediate Actions Required

• Inventory all Open5GS deployments and identify instances running version 2.7.7 or earlier
• Apply the upstream patch from the Open5GS repository once available for your branch
• Restrict network access to SBI interfaces using firewall rules limited to trusted 5G core peers
• Implement rate limiting on HTTP/2 connections to SBI endpoints

Patch Information

Review the Open5GS GitHub repository and Issue #4474 for the current patch status and recommended upgrade version. Apply the fix to all vulnerable nodes before reintroducing them into production signaling paths.

Workarounds

• Place Open5GS SBI endpoints behind a reverse proxy that enforces HTTP/2 stream limits
• Apply iptables or nftables rules to restrict SBI access to known 5G network function source addresses
• Configure process supervisors (systemd, Kubernetes liveness probes) to automatically restart degraded Open5GS services while patching is scheduled

# Configuration example: restrict SBI access via nftables
nft add rule inet filter input tcp dport 7777 ip saddr != { 10.0.0.0/24 } drop
nft add rule inet filter input tcp dport 7777 ct state new limit rate 50/second accept