CVE-2026-2062: Open5GS Null Pointer Dereference DoS Flaw

CVE-2026-2062 Overview

A null pointer dereference vulnerability has been identified in Open5GS versions up to 2.7.6. This vulnerability affects the sgwc_s5c_handle_modify_bearer_response and sgwc_sxa_handle_session_modification_response functions within the PGW S5U Address Handler component. The flaw allows remote attackers to cause a denial of service condition by sending specially crafted network requests that trigger the null pointer dereference.

Critical Impact

Remote attackers can crash the Open5GS SGW-C (Serving Gateway Control Plane) component, potentially disrupting 4G/5G mobile network connectivity for subscribers relying on the affected infrastructure.

Affected Products

• Open5GS versions up to and including 2.7.6
• SGW-C (Serving Gateway Control Plane) component
• PGW S5U Address Handler functionality

Discovery Timeline

• 2026-02-06 - CVE-2026-2062 published to NVD
• 2026-02-11 - Last updated in NVD database

Technical Details for CVE-2026-2062

Vulnerability Analysis

This vulnerability exists in the SGW-C component of Open5GS, an open-source implementation of the 4G/5G mobile core network. The affected functions handle the Modify Bearer Response message processing in the GTP-C (GPRS Tunneling Protocol - Control Plane) interface between the SGW and PGW.

When a Modify Bearer Response message is received without a valid PGW S5U address, the code attempts to access tunnel remote IP information without proper validation. The absence of defensive checks for uninitialized tunnel data leads to a null pointer dereference, causing the SGW-C process to crash.

The vulnerability is particularly concerning for mobile network operators as it can be triggered remotely over the network, potentially causing service disruptions for connected mobile devices.

Root Cause

The root cause stems from missing validation checks in two critical handler functions. The code failed to verify that the UL (Uplink) tunnel and its associated remote IP address were properly initialized before attempting to use them. Specifically:

1. In sgwc_s5c_handle_modify_bearer_response, the code did not check whether ul_tunnel was valid or whether the remote IP (IPv4 or IPv6) was initialized before proceeding with the path switch request handling
2. In sgwc_sxa_handle_session_modification_response, the return value from ogs_gtp2_ip_to_f_teid() was not properly checked, relying only on an assertion that could be bypassed

Attack Vector

The attack can be initiated remotely over the network interface. An attacker with network access to the SGW-C component can craft malicious GTP-C messages that lack the required PGW S5U address information. When the vulnerable functions process these malformed messages during the Modify Bearer Response handling, the null pointer dereference is triggered.

The exploit is publicly documented in GitHub Issue #4257, which provides details about the crash condition.

// Security patch in src/sgwc/s5c-handler.c
// Source: https://github.com/open5gs/open5gs/commit/f1bbd7b57f831e2a070780a7d8d5d4c73babdb59

        sess->sgw_s5c_teid, sess->pgw_s5c_teid);
 
    if (modify_action == OGS_GTP_MODIFY_IN_PATH_SWITCH_REQUEST) {
+        sgwc_bearer_t *bearer = NULL;
+        sgwc_tunnel_t *ul_tunnel = NULL;
+
+        ogs_list_for_each(&sess->bearer_list, bearer) {
+            ul_tunnel = sgwc_ul_tunnel_in_bearer(bearer);
+
+            /* Defensive check: UL tunnel remote IP must be initialized */
+            if (!ul_tunnel ||
+                (!ul_tunnel->remote_ip.ipv4 && !ul_tunnel->remote_ip.ipv6)) {
+
+                ogs_error("ModifyBearerResponse missing PGW S5U address "
+                        "(SEID=%u, bearer=%u)", sess->id, bearer->ebi);
+
+                ogs_gtp_send_error_message(
+                        s11_xact, sgwc_ue ? sgwc_ue->mme_s11_teid : 0,
+                        OGS_GTP2_CREATE_SESSION_RESPONSE_TYPE,
+                        OGS_GTP2_CAUSE_MANDATORY_IE_MISSING);
+                return;
+            }
+        }
+
        ogs_assert(OGS_OK ==
            sgwc_gtp_send_create_session_response(sess, s11_xact));
    } else {

The patch adds defensive validation to check that the UL tunnel exists and has a valid remote IP address before proceeding with message processing.

Detection Methods for CVE-2026-2062

Indicators of Compromise

• Unexpected SGW-C process crashes or restarts in Open5GS deployments
• Error log entries indicating "ModifyBearerResponse missing PGW S5U address"
• Abnormal GTP-C traffic patterns with malformed Modify Bearer Response messages
• Service disruptions affecting mobile subscriber connectivity

Detection Strategies

• Monitor Open5GS SGW-C process stability and crash logs for null pointer dereference errors
• Implement GTP-C protocol inspection to identify Modify Bearer Response messages lacking PGW S5U address information
• Configure alerting for unexpected process restarts in the SGW-C component
• Review system logs for segmentation fault signals in the sgwc process

Monitoring Recommendations

• Enable comprehensive logging for GTP-C message processing in Open5GS
• Monitor process uptime metrics for the SGW-C component
• Implement network traffic analysis for anomalous GTP-C message patterns
• Configure crash dump collection for forensic analysis of potential exploitation attempts

How to Mitigate CVE-2026-2062

Immediate Actions Required

• Apply the security patch identified by commit f1bbd7b57f831e2a070780a7d8d5d4c73babdb59
• Upgrade Open5GS to a patched version beyond 2.7.6
• Implement network segmentation to restrict access to the SGW-C GTP-C interface
• Enable process monitoring and automatic restart for the SGW-C component as a temporary measure

Patch Information

The vulnerability has been addressed in the Open5GS repository. The fix is available in commit f1bbd7b57f831e2a070780a7d8d5d4c73babdb59. Organizations running affected versions should apply this patch immediately or upgrade to a version containing the fix.

The patch adds proper validation checks in both affected handler functions:

1. Validates that ul_tunnel exists and has initialized remote IP addresses before proceeding
2. Replaces unsafe assertions with proper error handling and returns

Workarounds

• Restrict network access to the SGW-C component's GTP-C interface using firewall rules
• Implement rate limiting on GTP-C traffic to reduce the impact of potential denial of service attempts
• Configure process supervisors (e.g., systemd) to automatically restart the SGW-C service if a crash occurs
• Deploy redundant SGW-C instances to maintain service availability during potential exploitation

# Configuration example - Restrict GTP-C interface access
# Add firewall rules to limit access to SGW-C GTP-C port (typically 2123/UDP)
iptables -A INPUT -p udp --dport 2123 -s trusted_pgw_ip -j ACCEPT
iptables -A INPUT -p udp --dport 2123 -j DROP

# Configure systemd to automatically restart SGW-C on failure
# Edit /etc/systemd/system/open5gs-sgwcd.service
# [Service]
# Restart=always
# RestartSec=5