What is the CVSS score of CVE-2025-65568?

CVE-2025-65568 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.5%.

Which versions of OMEC UPF are affected by CVE-2025-65568?

The omec-project UPF (User Plane Function), a critical 5G mobile network component used in production mobile infrastructure, is vulnerable to remote denial-of-service attacks in version 2.1.3-dev.

Is there a public PoC exploit available for CVE-2025-65568?

Yes, a public proof-of-concept exploit is available for CVE-2025-65568. Prioritise patching immediately. EPSS: 0.5%.

How to fix or mitigate CVE-2025-65568?

24 hours: Conduct comprehensive inventory of all upf-epc-pfcpiface version 2.1.3-dev instances in production; determine network exposure of PFCP (port 8805 UDP) interface. 7 days: Implement firewall rules restricting PFCP access to authorized control-plane nodes only; isolate or take offline affected UPF instances if network exposure is confirmed. 30 days: Monitor omec-project GitHub repository for security patch release; develop upgrade plan to patched version once available from vendor.

OMEC UPF CVE-2025-65568

HIGH

Out-of-bounds Read (CWE-125)

2025-12-18 cve@mitre.org

Buffer Overflow Information Disclosure Upf

7.5

CVSS 3.1 · Vendor: mitre

Severity by source

Vendor (mitre) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

vuln.today AI

7.5 HIGH

PFCP N4 endpoint is network-reachable with no protocol authentication (AV:N/PR:N), a single malformed request reliably crashes the process (AC:L), and impact is availability-only (C:N/I:N/A:H).

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (mitre).

CVSS VectorVendor: mitre

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 05, 2026 - 03:30 vuln.today

DescriptionCVE.org

A denial-of-service vulnerability exists in the omec-project UPF (pfcpiface component) in version upf-epc-pfcpiface:2.1.3-dev. After PFCP association, a PFCP Session Establishment Request that includes a CreateFAR with an empty or truncated IPv4 address field is not properly validated. During parsing, parseFAR() calls ip2int(), which performs an out-of-bounds read on the IPv4 address buffer and triggers an index-out-of-range panic. An attacker who can send PFCP Session Establishment Request messages to the UPF's N4/PFCP endpoint can exploit this issue to repeatedly crash the UPF and disrupt user-plane services.

AnalysisAI

Remote denial-of-service in the omec-project UPF (pfcpiface component, version upf-epc-pfcpiface 2.1.3-dev) lets any endpoint able to reach the N4/PFCP interface crash the user-plane function by sending a malformed PFCP Session Establishment Request. The request carries a CreateFAR IE with an empty or truncated IPv4 address; parseFAR() passes it to ip2int(), which reads past the buffer and triggers a Go index-out-of-range panic (CWE-125). Publicly available exploit references exist via the upstream issue tracker, though EPSS remains low (0.46%) and it is not on CISA KEV.

Technical ContextAI

The affected component is pfcpiface, the Go control-plane agent for the OMEC (Open Mobile Evolved Core) UPF, a 4G/5G user-plane function developed under Open Networking Foundation and identified by CPE cpe:2.3:a:opennetworking:upf:2.1.3:dev. PFCP (Packet Forwarding Control Protocol, 3GPP TS 29.244) runs on the N4 interface and lets the SMF program forwarding rules - including FARs (Forwarding Action Rules) - into the UPF. The root cause is CWE-125 out-of-bounds read: parseFAR() invokes ip2int() on the FAR's IPv4 address field without validating that the buffer contains the expected four bytes, so an empty or truncated field causes a slice index beyond bounds and an unrecovered panic that terminates the process.

RemediationAI

No vendor-released patched version is identified at time of analysis - the only fix reference is the upstream issue https://github.com/omec-project/upf/issues/962, so monitor that issue and the omec-project/upf repository for a tagged release and upgrade once available. As compensating controls, restrict N4/PFCP reachability by network segmentation and firewalling the UPF's PFCP port (UDP 8805) so only the trusted SMF can send Session Establishment Requests - this is the highest-value mitigation with essentially no functional trade-off in a correctly designed core. Enforce PFCP peer allow-listing at the UPF so associations are only accepted from known SMF addresses (trade-off: requires accurate SMF inventory). If source modification is feasible, add input-length validation in parseFAR()/ip2int() to reject FARs whose IPv4 field is not four bytes and recover from the panic rather than crashing the process.