Open5GS EUVD-2026-95795

Exploitation requires three concrete conditions drawn from the description: (1) the malicious GTPv1-C packet must originate from or be spoofed as an address already configured on the MME as a trusted SGSN peer on the Gn interface; (2) the attacker must know a valid provisioned subscriber identifier - a UE IMSI or P-TMSI - to reference in the SGSN Context Request; and (3) the SGSN Address for Control Plane IE must carry an invalid address length that makes ogs_gtp1_gsn_addr_to_ip() fail. Limiting factors: although PR:N means no subscriber authentication is needed, the configured-SGSN-source and known-identifier prerequisites (encoded as AT:P) meaningfully constrain who can exploit this, and the impact is confined to a crash/DoS of open5gs-mmed with no code execution or data disclosure.

This is a genuine availability threat but not a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VA:H) correctly captures the core dynamics: network-reachable, unauthenticated (PR:N), high availability impact (VA:H), with no confidentiality or integrity exposure (VC:N/VI:N) - consistent with a CWE-617 reachable assertion that crashes a process rather than executing code. The key moderating signal is AT:P (attack requirements present), which reflects the description's prerequisites: traffic must originate from an address already configured as a trusted SGSN peer, and the attacker must know a valid subscriber IMSI or P-TMSI. These are real, non-trivial barriers that argue against trivial internet-wide mass exploitation, and they explain why the base score is 8.2 rather than a flat 9+ DoS. No EPSS score, KEV listing, or published POC was provided in the input, so exploitation probability cannot be quantified from the data and there is no evidence of in-the-wild activity. Signals are internally consistent - there is no CVSS-vs-description conflict here; the main gap is the absence of exploitation-likelihood telemetry (EPSS/KEV). Net: treat as a high-priority patch for anyone running Open5GS MME with the Gn/GTPv1 interface exposed to semi-trusted or spoofable networks, but the trust-boundary and subscriber-identifier prerequisites make it a targeted-DoS risk rather than an opportunistic one.

An attacker positioned to send GTPv1-C traffic that appears to come from a configured SGSN peer address crafts an SGSN Context Request referencing a known UE IMSI or P-TMSI, embedding an SGSN Address for Control Plane IE with an invalid length. When the MME parses it, ogs_gtp1_gsn_addr_to_ip() returns non-OK and the unchecked ogs_assert(rv == OGS_OK) fires, terminating open5gs-mmed and denying service to every subscriber on that core. No public exploit was identified in the provided data, though the root cause is fully visible in the published patch diff, lowering the effort to reproduce it.