CVE-2026-32937 in Free5GC
Summary
by MITRE • 03/20/2026
free5GC is an open source 5G core network. free5GC CHF prior to version 1.2.2 has an out-of-bounds slice access vulnerability in the CHF `nchf-convergedcharging` service. A valid authenticated request to PUT `/nchf-convergedcharging/v3/recharging/:ueId?ratingGroup=...` can trigger a server-side panic in `github.com/free5gc/chf/internal/sbi.(*Server).RechargePut(...)` due to an out-of-range slice access. In the reported runtime, Gin recovery converts the panic into HTTP 500, but the recharge path remains remotely panic-triggerable and can be abused repeatedly to degrade recharge functionality and flood logs. In deployments without equivalent recovery handling, this panic may cause more severe service disruption. free5GC CHF patches the issue. Some workarounds are available: Restrict access to the `nchf-convergedcharging` recharge endpoint to strictly trusted NF callers only; apply rate limiting or network ACLs in front of the CHF SBI interface to reduce repeated panic-trigger attempts; if the recharge API is not required, temporarily disable or block external reachability to this route; and/or ensure panic recovery, monitoring, and alerting are enabled.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/27/2026
The vulnerability CVE-2026-32937 affects the free5GC open source 5G core network implementation, specifically within the Charging Function (CHF) component. This issue resides in the nchf-convergedcharging service where an out-of-bounds slice access flaw exists in the recharge functionality. The vulnerability manifests when a valid authenticated user sends a PUT request to the endpoint `/nchf-convergedcharging/v3/recharging/:ueId?ratingGroup=...` which triggers a server-side panic within the Go application's handling code at `github.com/free5gc/chf/internal/sbi.(*Server).RechargePut(...)`. This represents a classic buffer overflow condition where array indexing occurs beyond the allocated memory boundaries, leading to undefined behavior and system instability.
The technical exploitation of this vulnerability demonstrates a critical flaw in input validation and memory management within the CHF's SBI (Service-Based Interface) implementation. The issue stems from improper bounds checking when processing the ratingGroup parameter in the recharge request, causing the application to attempt accessing memory locations outside the valid slice boundaries. This type of vulnerability maps directly to CWE-129, which describes "Improper Validation of Array Index" and aligns with ATT&CK technique T1210 for exploitation through manipulation of input parameters. The Gin web framework's recovery mechanism converts this panic into an HTTP 500 error response, but the underlying panic condition remains exploitable and can be repeatedly triggered by attackers.
The operational impact of this vulnerability extends beyond simple service disruption, creating potential for sustained degradation of the charging functionality within the 5G core network. Attackers can repeatedly exploit this vulnerability to flood system logs with panic messages while simultaneously degrading the recharge service's availability and performance. In environments lacking proper panic recovery mechanisms, this could lead to complete service outages or system crashes, severely impacting network operations and user experience. The vulnerability affects the core charging infrastructure that manages billing and resource allocation in 5G networks, making it particularly dangerous for production deployments where continuous service availability is critical.
The mitigation strategies recommended for this vulnerability encompass multiple layers of defense to protect against exploitation. Network segmentation and access control measures, such as restricting the nchf-convergedcharging endpoint to only trusted Network Functions, provide a fundamental defense against unauthorized exploitation. Rate limiting and network ACLs implemented at the SBI interface level can significantly reduce the effectiveness of repeated exploitation attempts by limiting the frequency of requests that can trigger the panic condition. Organizations should also consider temporarily disabling or blocking external access to the recharge API endpoint if it is not required for immediate operations. Additionally, implementing comprehensive panic recovery mechanisms, monitoring systems, and alerting protocols ensures that any exploitation attempts are quickly detected and responded to, preventing the vulnerability from causing extended service disruption. These measures align with security best practices for protecting critical network infrastructure components against both known and unknown vulnerabilities.