CVE-2025-15176
Reachable Assertion in Open5GS PFCP Session Handler
Publication date: 2025-12-29
Last updated on: 2026-02-24
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| open5gs | open5gs | 2.7.5 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-617 | The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-15176 is a vulnerability in Open5GS up to version 2.7.5 affecting the User Plane Function (UPF) component, specifically in the PFCP Session Establishment Request Handler. The issue occurs in the functions decode_ipv6_header and ogs_pfcp_pdr_rule_find_by_packet when processing IPv6 packets with a jumbo payload option where the Payload Length is zero but the Next Header field is non-zero. This causes an assertion failure (ogs_assert(nxt == 0)) leading to the UPF process aborting unexpectedly. An attacker can exploit this remotely by sending specially crafted PFCP or GTP-U packets with malformed IPv6 headers, causing a denial of service (DoS) by crashing the UPF daemon. The vulnerability arises from improper validation of IPv6 header fields and can be triggered without authentication. A patch has been released to replace the assertion with proper error handling to prevent the crash. [1, 2, 3, 4]
How can this vulnerability impact me? :
This vulnerability can cause a remote Denial of Service (DoS) on systems running vulnerable versions of Open5GS UPF. By sending crafted packets with malformed IPv6 headers, an attacker can trigger an assertion failure that crashes the UPF process, leading to service disruption and loss of availability. This can impact network reliability and availability, requiring a restart of the UPF daemon to restore service. Since the attack can be performed remotely without authentication, it poses a significant risk to network infrastructure relying on Open5GS for packet forwarding and session management. [1, 3, 4]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for crashes or assertion failures in the Open5GS UPF process (open5gs-upfd), specifically looking for logs indicating assertion failure in decode_ipv6_header() such as "Assertion 'nxt == 0' failed". Detection involves capturing and analyzing PFCP Session Establishment Requests and GTP-U packets with IPv6 headers where the Payload Length is zero but the Next Header field is non-zero (e.g., UDP). Network packet capture tools like tcpdump or Wireshark can be used to filter and inspect such malformed packets. For example, you can use tcpdump to capture GTP-U packets and filter IPv6 packets with suspicious header fields. A sample tcpdump command might be: `tcpdump -i <interface> udp port 2152 -w capture.pcap` (GTP-U typically uses UDP port 2152). Then analyze the capture for IPv6 packets with Payload Length = 0 and Next Header != 0. Additionally, monitoring Open5GS logs for process crashes or abnormal terminations can help detect exploitation attempts. [1, 3, 4]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to apply the available patch that fixes the vulnerability by replacing the unsafe assertion with proper validation and error handling. The patch identified by commit ID b72d8349980076e2c033c8324f07747a86eea4f8 modifies the file lib/pfcp/rule-match.c to safely handle malformed IPv6 jumbo payload packets, preventing the UPF process from crashing. Until the patch is applied, consider implementing network-level filtering to block malformed PFCP Session Establishment Requests or GTP-U packets with IPv6 headers having Payload Length zero and non-zero Next Header fields. Monitoring and alerting on UPF process crashes and restarting the service promptly can reduce downtime. Applying the patch is strongly recommended to fully resolve the issue. [1, 2]