CVE-2026-108105 Overview
CVE-2026-108105 is a reachable assertion vulnerability [CWE-617] in Open5GS versions through 2.8.0. The flaw resides in the mme_gn_handle_sgsn_context_request() function within the Mobility Management Entity (MME) component. Remote unauthenticated attackers can crash the open5gs-mmed process by sending malformed SGSN Address Information Elements (IEs) over GTPv1-C. A successful trigger terminates the MME daemon and denies service to all connected subscribers.
Critical Impact
An attacker sending GTPv1-C traffic from a configured SGSN address with a known UE IMSI or P-TMSI can supply an invalid address length to crash the MME, causing network-wide service denial for every subscriber attached to the affected mobile core.
Affected Products
- Open5GS versions up to and including 2.8.0
- Open5GS MME component (open5gs-mmed)
- Deployments exposing GTPv1-C interfaces to configured SGSN peers
Discovery Timeline
- 2026-10-09 - CVE-2026-108105 published to the National Vulnerability Database (NVD)
- 2026-10-09 - Last updated in NVD database
Technical Details for CVE-2026-108105
Vulnerability Analysis
The vulnerability affects the Gn interface handler used for inter-RAT handover between legacy SGSN nodes and the Open5GS MME. When processing a GTPv1-C SGSN Context Request, the handler parses SGSN Address IEs without validating the declared address length against expected IPv4 or IPv6 sizes. An out-of-range length value triggers an internal assertion in the Open5GS logging and IP parsing layer. The assertion abort terminates open5gs-mmed, removing EPS Mobility Management services for all UEs.
Because the MME is a central control-plane element, loss of the daemon prevents attach, handover, and bearer establishment procedures across the entire served PLMN.
Root Cause
The root cause is missing input validation in src/mme/mme-gn-handler.c around lines 208-217. The handler trusts the length field provided in the SGSN Address IE and passes it to downstream IP conversion routines. These routines enforce a strict assertion on the address length, which aborts the process when the untrusted value is neither 4 nor 16 bytes. The fix introduces explicit ogs_ip_t sgsn_gn_ip and sgsn_gn_ip_alt structures and validates addresses before dereferencing them.
Attack Vector
Exploitation requires the attacker to send GTPv1-C traffic sourced from an IP address already configured as a trusted SGSN peer in the MME. The attacker must also know a valid UE IMSI or P-TMSI to construct a routable Context Request. With those preconditions met, delivering a single packet containing a malformed SGSN Address IE length is sufficient to crash the MME.
// Source: https://github.com/open5gs/open5gs/commit/346ce7a5e5cf2812bac3af042b5afba35bcf4f89
// Patch excerpt: src/mme/mme-gn-handler.c
ogs_nas_eps_guti_t nas_guti;
ogs_plmn_id_t plmn_id;
ogs_nas_rai_t rai;
+ ogs_ip_t sgsn_gn_ip, sgsn_gn_ip_alt;
mme_ue_t *mme_ue = NULL;
int rv;
The patch adds dedicated ogs_ip_t structures used by validation logic that rejects malformed SGSN address lengths before the assertion path is reached.
Detection Methods for CVE-2026-108105
Indicators of Compromise
- Unexpected termination or repeated restarts of the open5gs-mmed process
- Assertion failure messages in Open5GS logs referencing IP parsing or address length checks
- Inbound GTPv1-C SGSN Context Request messages originating from configured SGSN peers with abnormal IE lengths
- Sudden mass UE detach or attach failures across the served PLMN
Detection Strategies
- Monitor control-plane traffic on UDP port 2123 for GTPv1-C messages containing SGSN Address IEs with length fields other than 4 or 16 bytes
- Correlate MME daemon crashes with inbound Gn interface traffic from SGSN peers
- Alert on process supervisors (systemd, container orchestrators) restarting open5gs-mmed within short intervals
Monitoring Recommendations
- Enable verbose logging on the MME Gn handler to capture malformed IE events
- Forward Open5GS logs and host telemetry to a centralized analytics platform for correlation across control-plane nodes
- Baseline normal SGSN Context Request volume and alert on anomalies from peer SGSN addresses
How to Mitigate CVE-2026-108105
Immediate Actions Required
- Upgrade Open5GS to a release containing commit 346ce7a5e5cf2812bac3af042b5afba35bcf4f89 or later
- Restrict GTPv1-C exposure so only trusted SGSN peers can reach the MME on UDP 2123
- Review the configured SGSN peer list in MME configuration and remove unused entries
- Deploy process supervision to restart open5gs-mmed on crash while remediation is scheduled
Patch Information
The fix is applied in the Open5GS repository under commit 346ce7a5e5cf2812bac3af042b5afba35bcf4f89, which validates SGSN addresses in mme_gn_handle_sgsn_context_request() before passing them to IP conversion routines. Reference the Open5GS commit details, the GitHub Security Advisory GHSA-9crh-64c8-56q6, and the VulnCheck Advisory on Open5GS for full technical context.
Workarounds
- Firewall UDP port 2123 to permit traffic only from known SGSN IP addresses on the signaling network
- Disable the Gn interface in MME configuration if inter-RAT handover with legacy SGSN nodes is not required
- Place the MME behind a GTP-aware security gateway capable of validating IE length fields
# Example iptables rule restricting GTPv1-C (UDP/2123) to a known SGSN peer
iptables -A INPUT -p udp --dport 2123 -s <trusted_sgsn_ip> -j ACCEPT
iptables -A INPUT -p udp --dport 2123 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

