CVE-2026-106805 in Free5GC
Summary
by MITRE • 11/02/2026
A resource exhaustion issue exists in Free5GC v4.2.3 during PFCP Session Establishment failure handling. When the SMF does not receive a PFCP Session Establishment Response from the UPF, allocated UE IP address resources are not properly released. Repeated failed session establishment attempts can therefore exhaust the UE IP address pool, preventing new UEs from establishing PDU sessions and resulting in denial of service.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Free5GC version 4.2.3 represents a critical resource exhaustion flaw within the Session Management Function component during the handling of Packet Forwarding Control Protocol session establishment failures. This issue specifically manifests when the SMF initiates a PFCP Session Establishment Request to the User Plane Function but fails to receive a corresponding response, indicating either network latency, UPF unavailability, or protocol-level errors. Under normal operational conditions, if such a request times out or is explicitly rejected, the system should immediately release any temporarily allocated resources associated with that specific session attempt. However, in this vulnerable version, the logic governing resource cleanup is incomplete, causing the SMF to retain ownership of IP addresses assigned from its pool even after the session establishment process has effectively failed or timed out without successful completion.
From a technical perspective, the flaw lies in the state management and transaction handling mechanisms within the PFCP client implementation of the SMF. When an outgoing request is sent, the system reserves an IP address for potential use by the User Equipment to ensure continuity if the session succeeds. The defect occurs because there is no robust timeout handler or error path that triggers a release function when the expected response does not arrive within a defined window. Consequently, these reserved addresses remain in a locked state, effectively removed from the available pool despite being unused and unassigned to any active data plane context. This behavior creates a gradual but steady depletion of the IP address space allocated for UE sessions, which is typically finite and strictly bounded by network configuration parameters.
The operational impact of this vulnerability is severe, primarily resulting in a Denial of Service condition for new User Equipment attempting to connect to the 5G core network. As repeated failed session establishment attempts accumulate due to transient network issues or malicious probing, the IP address pool becomes exhausted. Once depleted, legitimate UEs are unable to establish PDU sessions because no available addresses exist to assign them. This leads to a complete service outage for new connections, although existing active sessions may continue unaffected until they also terminate and release their resources. The severity is compounded by the fact that this exhaustion can occur without any malicious intent from external actors if underlying network instability causes frequent timeouts, making it both an operational reliability risk and a potential target for denial-of-service attacks where adversaries deliberately trigger session establishment failures to accelerate pool depletion.
This vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, specifically the failure to properly release resources after use or upon error conditions. In terms of adversarial tactics, this flaw can be exploited via ATT&CK technique T1498, Network Denial of Service, where an attacker floods the SMF with invalid PFCP requests to exhaust system resources and disrupt service availability. To mitigate this risk, it is imperative that Free5GC developers implement rigorous timeout handling mechanisms within the PFCP client module. This includes ensuring that any IP address reserved during a session establishment attempt is automatically released back to the pool if no response is received within a configured time limit or if an explicit error message indicates failure. Additionally, implementing rate limiting on incoming PFCP requests and adding monitoring alerts for rapid depletion of the IP address pool can help detect and prevent such exhaustion events in production environments until a patched version is deployed.