CVE-2026-106807 in Open5GS
Summary
by MITRE • 11/02/2026
A denial-of-service vulnerability exists in open5GS v2.8.0 in the PFCP transaction handling path. When the PFCP transaction or timer resource pool is exhausted, ogs_pfcp_xact_remote_create() returns NULL, but the failure is not handled properly and leads to an ogs_assert(new) failure in ogs_pfcp_xact_receive(). An attacker able to send PFCP messages to the affected SMF/UPF can exhaust transaction resources and cause the network function process to terminate with SIGABRT, resulting in service disruption and preventing further session establishment until the affected component is restarted.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in open5GS versions up to 2.8.0 represents a critical flaw within the Packet Forwarding Control Protocol (PFCP) transaction handling mechanism of the Session Management Function (SMF) and User Plane Function (UPF). PFCP is the protocol responsible for controlling the user plane, specifically managing session establishment, modification, and deletion between control plane entities like the SMF and data forwarding elements known as UPFs. The core technical flaw resides in how the application manages resource allocation during high-load or maliciously induced scenarios. When an attacker sends a sustained stream of PFCP messages to the affected network function, they can rapidly exhaust the limited pool of transaction identifiers and associated timer resources maintained by the system. This exhaustion triggers a specific code path where the internal function ogs_pfcp_xact_remote_create() fails to allocate new transaction context objects and consequently returns NULL instead of a valid pointer.
The severity of this vulnerability is compounded by improper error handling within the receiving logic, specifically in the ogs_pfcp_xact_receive() function. Rather than gracefully degrading service or returning an appropriate protocol-level error message such as Cause Code 13 (Resource Unavailable) to signal the sender that resources are exhausted, the code proceeds with a null pointer dereference check that relies on an assertion macro. The expression ogs_assert(new) expects new to be non-null; however, because it is NULL due to resource exhaustion, this assertion fails. In most production builds of open5GS, assertions result in immediate termination of the process via SIGABRT signal rather than a controlled exception or error return code. This design choice transforms what could have been a manageable service degradation into a catastrophic failure where the entire SMF or UPF process crashes and exits unexpectedly.
From an operational perspective, this denial-of-service vulnerability allows any entity with network access to the PFCP interface on port 2152 UDP/TCP to disrupt critical telecommunications infrastructure. The immediate impact is the termination of the affected network function process, which leads to a complete loss of service for all sessions currently managed by that instance. New session establishment attempts will fail because the control plane component responsible for orchestrating these sessions is no longer running. Recovery requires manual intervention or an automated restart mechanism to bring the SMF/UPF back online, during which time mobile subscribers experience dropped calls and lost data connectivity. This constitutes a significant availability risk in 5G core networks where high reliability is paramount.
This vulnerability aligns with CWE-400: Uncontrolled Resource Consumption, as the application fails to properly limit or manage resource usage under attack conditions. Furthermore, it maps directly to MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically within the context of network service disruption through exhaustion of computational resources. The lack of proper error handling for allocation failures also reflects CWE-252: Checkpoint Failure and CWE-703: Improper Check or Handling of Exceptional Conditions. To mitigate this risk, operators should ensure they are running patched versions of open5GS where the NULL return value from transaction creation is explicitly checked before proceeding with assertion logic. Implementing rate limiting on incoming PFCP messages at the network perimeter can also help prevent resource exhaustion by filtering out excessive traffic from untrusted sources. Additionally, deploying health checks and automatic restart policies for critical control plane functions can minimize downtime during such incidents while longer-term code fixes are applied to ensure robust error handling in all failure paths of the transaction management subsystem.