CVE-2025-15555: Open5GS Buffer Overflow Vulnerability

CVE-2025-15555 Overview

A stack-based buffer overflow vulnerability has been discovered in Open5GS, an open-source implementation of the 5G Core and EPC (Evolved Packet Core) networks. The vulnerability exists in the hss_ogs_diam_cx_mar_cb function within the src/hss/hss-cx-path.c file, which is part of the VoLTE Cx-Test component. An attacker can exploit this flaw by manipulating the OGS_KEY_LEN argument, leading to a stack-based buffer overflow condition that can be triggered remotely over the network.

Critical Impact

Remote attackers can exploit this stack-based buffer overflow in Open5GS HSS (Home Subscriber Server) to potentially corrupt memory, crash the service, or achieve code execution in telecommunications infrastructure deployments.

Affected Products

• Open5GS versions up to and including 2.7.6
• Open5GS HSS (Home Subscriber Server) component
• VoLTE Cx Interface implementations using affected Open5GS versions

Discovery Timeline

• 2026-02-04 - CVE-2025-15555 published to NVD
• 2026-02-05 - Last updated in NVD database

Technical Details for CVE-2025-15555

Vulnerability Analysis

This vulnerability is classified as CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer), manifesting as a stack-based buffer overflow in the Open5GS Home Subscriber Server. The vulnerable function hss_ogs_diam_cx_mar_cb handles Diameter protocol Multimedia-Auth-Request (MAR) messages as part of the Cx interface implementation used for IMS/VoLTE authentication.

The Cx interface is a critical component in VoLTE (Voice over LTE) deployments, facilitating communication between the Call Session Control Function (CSCF) and the HSS for subscriber authentication and authorization. When processing authentication requests, the function fails to properly validate the bounds of buffer operations involving the OGS_KEY_LEN parameter, allowing an attacker to write beyond allocated stack memory.

Successful exploitation could allow an attacker to overwrite adjacent stack variables, corrupt return addresses, or inject malicious payloads. In telecommunications environments, this could lead to service disruption of VoLTE services, unauthorized access to subscriber data, or potential lateral movement within the core network infrastructure.

Root Cause

The root cause of this vulnerability lies in insufficient bounds checking when handling the OGS_KEY_LEN argument in the Diameter Cx interface message processing code. The hss_ogs_diam_cx_mar_cb callback function processes incoming MAR (Multimedia-Auth-Request) messages but fails to properly validate the size of key-related data before copying it into a fixed-size stack buffer, leading to a classic stack-based buffer overflow condition.

Attack Vector

The vulnerability can be exploited remotely over the network without requiring authentication. An attacker with network access to the Open5GS HSS Diameter interface can craft malicious Cx protocol messages containing oversized or malformed OGS_KEY_LEN values. When the HSS processes these specially crafted authentication requests, the buffer overflow is triggered in the callback function, potentially allowing memory corruption or code execution on the target system.

The attack surface is exposed on deployments where the Diameter Cx interface is accessible, which may include internal telecommunications networks or improperly segmented 5G/LTE core infrastructure.

Detection Methods for CVE-2025-15555

Indicators of Compromise

• Unexpected crashes or restarts of the Open5GS HSS process (open5gs-hssd)
• Abnormal Diameter protocol traffic patterns targeting the Cx interface
• Memory corruption indicators in system logs or core dumps from the HSS service
• Unusual MAR (Multimedia-Auth-Request) messages with malformed or oversized key parameters

Detection Strategies

• Deploy network intrusion detection systems (IDS) to monitor Diameter protocol traffic for anomalous message sizes or malformed AVPs (Attribute-Value Pairs)
• Implement application-level logging to capture and analyze Cx interface message processing, particularly MAR transactions
• Monitor Open5GS HSS process health for unexpected terminations, high memory usage, or abnormal behavior patterns
• Use memory protection tools (AddressSanitizer, Valgrind) in test environments to detect buffer overflow attempts

Monitoring Recommendations

• Configure alerting for Open5GS HSS service crashes or unexpected restarts
• Establish baseline metrics for Diameter Cx interface traffic volume and message characteristics
• Implement centralized logging for all 5G/LTE core network components with correlation capabilities
• Review network segmentation to ensure Diameter interfaces are not exposed to untrusted networks

How to Mitigate CVE-2025-15555

Immediate Actions Required

• Apply the security patch identified by commit 54dda041211098730221d0ae20a2f9f9173e7a21 immediately
• Upgrade Open5GS to a version newer than 2.7.6 that includes the fix
• Restrict network access to the Diameter Cx interface to trusted internal networks only
• Implement network segmentation to isolate HSS components from potential attack vectors

Patch Information

A fix for this vulnerability has been committed to the Open5GS repository. The patch is identified by commit hash 54dda041211098730221d0ae20a2f9f9173e7a21. Organizations running affected versions should update to the latest Open5GS release that includes this fix. For detailed information about the vulnerability and the patch, refer to GitHub Issue #4177 and the security commit.

Workarounds

• Implement strict network access controls to limit Diameter interface exposure to trusted endpoints only
• Deploy a web application firewall (WAF) or Diameter edge agent capable of inspecting and filtering malformed protocol messages
• Enable Address Space Layout Randomization (ASLR) and stack canaries on systems running Open5GS to reduce exploitation success probability
• Consider temporarily disabling the Cx interface if VoLTE services are not critical while awaiting patch deployment

# Example: Restrict Diameter interface access using iptables
# Replace 10.0.0.0/24 with your trusted network range
iptables -A INPUT -p tcp --dport 3868 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 3868 -j DROP
iptables -A INPUT -p sctp --dport 3868 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p sctp --dport 3868 -j DROP