CVE-2026-108105 in Open5GS
Summary
by MITRE • 10/09/2026
Open5GS through 2.8.0 contains a reachable assertion vulnerability in mme_gn_handle_sgsn_context_request() that allows remote unauthenticated attackers to crash the MME via malformed SGSN Address IEs. Attackers sending GTPv1-C traffic from a configured SGSN address with a known UE IMSI or P-TMSI can supply an invalid address length to terminate open5gs-mmed, denying service to all subscribers.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in Open5GS versions through 2.8.0 represents a critical denial-of-service risk within the Mobility Management Entity component of the Evolved Packet Core network architecture. Specifically, this flaw resides in the mme_gn_handle_sgsn_context_request function, which is responsible for processing signaling messages related to inter-system mobility between LTE and legacy GSM/UMTS networks via the SGSN interface. The core technical deficiency involves an insufficient validation mechanism for incoming GTPv1-C packets that contain Service Gateway Node or Serving GPRS Support Node address information elements. When a remote unauthenticated attacker sends malformed traffic from a configured SGSN address, they can inject an invalid length value into these address fields. Because the application logic fails to properly verify this integer before processing it as part of memory allocation or buffer handling operations, the assertion condition triggers unexpectedly during runtime execution. This failure causes the open5gs-mmed process to terminate abruptly rather than gracefully rejecting the malformed packet with a proper error code.
From an operational perspective, the impact of this vulnerability is severe due to its potential for complete service disruption within the mobile network operator's infrastructure. Since the Mobility Management Entity serves as the central control point for managing subscriber sessions and mobility states, crashing this process effectively halts all signaling activities associated with connected users. Attackers who possess knowledge of a valid User Equipment IMSI or P-TMSI can exploit this flaw to trigger the crash repeatedly, resulting in a sustained denial-of-service condition that affects every subscriber currently attached to or attempting to attach to the network via the affected SGSN interface. This not only disrupts voice and data services for legitimate users but also creates significant operational overhead as administrators must manually restart the service processes to restore connectivity, thereby increasing downtime and potential revenue loss for the telecommunications provider.
This vulnerability aligns with CWE-617, which describes a reachable assertion failure that can lead to application crashes or denial of service. In terms of offensive security frameworks such as MITRE ATT&CK, this exploit technique falls under T1498 Network Denial of Service, specifically reflecting the sub-category of network resource exhaustion through targeted signaling attacks against critical infrastructure components. The attack vector is classified as remote and unauthenticated, meaning no prior credentials or successful authentication handshake are required to initiate the malicious GTPv1-C traffic, provided the attacker can reach the MME's S-GW/SGSN interface IP address over the network.
Mitigation strategies for this vulnerability primarily involve upgrading Open5GS to a version later than 2.8.0 where the input validation logic has been corrected to handle invalid length values gracefully without triggering fatal assertions. In environments where immediate patching is not feasible, defensive measures should include implementing strict access control lists on the network perimeter to restrict GTP-C traffic sources exclusively to trusted SGSN IP addresses known to belong to legitimate partner networks or internal infrastructure components. Additionally, deploying deep packet inspection solutions capable of validating GTP header structures and length fields against expected standards can help filter out malformed packets before they reach the vulnerable application layer logic. Regular monitoring of MME process health metrics should also be established to detect unexpected service restarts that may indicate ongoing exploitation attempts.