CVE-2026-8187
Resource Exhaustion in Open5GS UPF Component
Publication date: 2026-05-09
Last updated on: 2026-05-09
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| open5gs | open5gs | to 2.7.7 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-404 | The product does not release or incorrectly releases a resource before it is made available for re-use. |
| CWE-400 | The product does not properly control the allocation and maintenance of a limited resource. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in Open5GS up to version 2.7.7, specifically in the function _gtpv1_u_recv_cb within the UPF component. It involves the handling of GTP-U traffic, where malicious or malformed packets with invalid or unknown TEIDs cause the system to perform expensive error handling and logging operations synchronously. This leads to resource consumption and degradation of the user-plane performance.
How can this vulnerability impact me? :
The vulnerability can cause significant resource exhaustion in the Open5GS UPF component when subjected to abusive GTP-U traffic. This results in increased latency, with round-trip times spiking from 1-3 milliseconds to over 100 or even 300 milliseconds, and packet loss increasing from near 0% to over 5-10%. Legitimate user-plane traffic experiences degradation, including delays and loss, although PDU sessions may remain active.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring the Open5GS UPF component for signs of resource exhaustion caused by abusive GTP-U traffic. Specifically, look for increased latency and packet loss in user-plane traffic, which may indicate the UPF is overwhelmed by malicious GTP-U Echo Requests and G-PDUs with invalid or unknown TEIDs.
Detection can be performed by generating controlled traffic similar to the abusive patterns described and measuring the system's response, such as round-trip time (RTT) spikes and packet loss.
While specific commands are not provided in the resources, typical network monitoring commands that could help include:
- Using tcpdump or tshark to capture and analyze GTP-U traffic on the UPF interface, e.g., `tcpdump -i <interface> udp port 2152`
- Using ping or traceroute to measure latency spikes and packet loss in the user-plane network.
- Monitoring system resource usage (CPU, memory) on the UPF host with commands like `top`, `htop`, or `vmstat` during suspected attacks.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include limiting or filtering abusive GTP-U traffic to prevent resource exhaustion on the UPF.
Since the vulnerability arises from the UPF performing expensive error handling and logging on invalid or unknown TEIDs, implementing rate-limiting or dropping such traffic cheaply before it reaches the UPF can reduce the impact.
Additionally, monitoring and alerting on unusual spikes in latency and packet loss can help detect ongoing attacks early.
As the project has not yet responded with a fix, network operators should consider deploying network-level protections such as firewall rules or traffic shaping to block or limit suspicious GTP-U Echo Requests and malformed G-PDUs.