CVE-2025-65564

7.5 HIGH

📋 TL;DR

A denial-of-service vulnerability in omec-upf's PFCP interface allows attackers to crash the UPF process by sending malformed PFCP Association Setup Requests missing the mandatory Recovery Time Stamp. This disrupts user-plane services in 5G networks. Organizations running vulnerable versions of omec-upf are affected.

💻 Affected Systems

Products:
  • omec-project upf (upf-epc-pfcpiface)
Versions: upf-epc-pfcpiface:2.1.3-dev
Operating Systems: Linux
Default Config Vulnerable: ⚠️ Yes
Notes: Only affects deployments using the vulnerable PFCP interface component. Requires N4/PFCP endpoint to be accessible.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Complete disruption of user-plane services in affected 5G network segments, causing service outages for all connected users until UPF restarts.

🟠

Likely Case

Intermittent service disruptions as attackers repeatedly crash UPF instances, requiring manual intervention and restarting processes.

🟢

If Mitigated

Minimal impact with proper network segmentation and monitoring allowing quick detection and response to attack attempts.

🌐 Internet-Facing: MEDIUM - Requires access to N4/PFCP endpoint which may be exposed in some deployments but typically behind network boundaries.
🏢 Internal Only: HIGH - Internal attackers or compromised internal systems can easily exploit this to disrupt critical network functions.

🎯 Exploit Status

Public PoC: ✅ No
Weaponized: LIKELY
Unauthenticated Exploit: ⚠️ Yes
Complexity: LOW

Exploitation requires only the ability to send PFCP packets to the vulnerable endpoint. No authentication or special privileges needed.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: Fixed in commit referenced in GitHub PR #964

Vendor Advisory: https://github.com/omec-project/upf/issues/956

Restart Required: Yes

Instructions:

1. Update to patched version from GitHub repository 2. Rebuild the upf-epc-pfcpiface component 3. Restart UPF services 4. Verify the fix by checking logs for successful PFCP associations

🔧 Temporary Workarounds

Network Access Control

linux

Restrict access to N4/PFCP endpoint (typically port 8805) to trusted management systems only

iptables -A INPUT -p udp --dport 8805 -s trusted_ip -j ACCEPT
iptables -A INPUT -p udp --dport 8805 -j DROP

🧯 If You Can't Patch

  • Implement strict network segmentation to isolate UPF N4 interface from untrusted networks
  • Deploy rate limiting on PFCP traffic and monitor for abnormal association setup patterns

🔍 How to Verify

Check if Vulnerable:

Check if running version 2.1.3-dev of upf-epc-pfcpiface and monitor logs for panic messages related to PFCP Association Setup

Check Version:

Check build version in UPF configuration or run: dpkg -l | grep upf-epc-pfcpiface or equivalent package manager command

Verify Fix Applied:

After patching, test by sending valid PFCP Association Setup Requests and verify UPF doesn't crash. Check logs for successful processing.

📡 Detection & Monitoring

Log Indicators:

  • UPF process panic/crash logs
  • nil pointer dereference errors
  • PFCP association failures

Network Indicators:

  • Unusual volume of PFCP Association Setup Requests
  • PFCP packets missing Recovery Time Stamp IE

SIEM Query:

source="upf.log" AND (panic OR "nil pointer" OR "dereference" OR "PFCP association failed")

🔗 References

📤 Share & Export