A flaw has been found in Open5GS up to 2

CVE-2026-8187 is a resource-consumption flaw in Open5GS UPF affecting all versions up to and including 2.7.7. The weak spot is _gtpv1_u_recv_cb in src/upf/gtp-path.c, the hot receive path for GTP-U traffic. Per the public GitHub report, a sustained mix of GTP-U Echo Requests and G-PDUs with invalid or unknown TEIDs can push the UPF into expensive logging and response handling, degrading legitimate user-plane traffic with inflated latency and packet loss.

The vendor's MEDIUM label is basically right, but the raw AV:N/PR:N CVSS framing overstates how reachable this really is in enterprise deployments. An attacker does not need credentials, but they do need L3 reachability to the UPF's UDP/2152 GTP-U interface, which is usually on a carrier/private-5G transport segment rather than broadly internet-exposed. This is a serious operational nuisance for operators running Open5GS, not a fleet-wide emergency for general enterprise patch teams.

Why this verdict

• Reachability is the whole game — CVSS says AV:N, but in reality the attacker needs L3 access to UDP/2152 on the UPF, which usually implies internal mobile transport, private-5G fabric, or a misconfigured exposed user-plane edge. That is a major downward adjustment from generic internet-reachable software.
• Impact is availability-only and local to the node path — the public report shows latency and loss inflation, not code execution, persistence, or data compromise. That keeps the score out of HIGH even though the UPF is operationally important.
• Threat intel is cold — no KEV, no campaign reporting, and a tiny EPSS (0.00032) mean there is no evidence this is being weaponized at scale.
• Population is narrow — Open5GS is not a mass-market enterprise platform, and only the UPF path is relevant. Requiring the right product, the right component, and the right network reachability compounds the friction.
• Still not LOW — if you *do* run Open5GS, the UPF is a choke point. Unauthenticated packet abuse against a subscriber datapath can create visible customer impact even without a full outage.

Why not higher?

This is not a general-purpose internet service bug with broad reachable population. The attacker must already be able to hit the GTP-U interface, and the public evidence points to service degradation rather than host takeover, cross-tenant compromise, or reliable crash-on-demand across all deployments.

Why not lower?

It is still pre-auth once reachability exists, and it targets a critical forwarding function rather than some dead-end helper daemon. For organizations actually operating Open5GS, this can hurt production traffic quality fast enough to deserve more than backlog-only treatment.

1. Filter GTP-U to known peers — Restrict UDP/2152 so only approved gNB/RAN or transport peers can reach the UPF. This is the highest-value control because it removes the main attack prerequisite; for a MEDIUM verdict there is no formal noisgate mitigation SLA, but if your UPF is currently broader than intended, fix that in the next change window, not whenever someone gets around to it.
2. Rate-limit untrusted UDP/2152 traffic — Apply policers or ACL-based rate controls on the edge closest to the UPF-facing transport so Echo floods and invalid TEID sprays cannot monopolize the receive path. Use this where peer allowlisting is incomplete or where private-5G labs have looser topology; again, no formal mitigation SLA for MEDIUM, but do it before the next routine maintenance cycle if exposure exists.
3. Isolate UPF transport — Put the UPF GTP-U side in a dedicated VRF/VLAN/security zone separate from general server networks. That reduces the chance that a foothold on ordinary enterprise infrastructure can laterally reach the user plane.
4. Tune alerting on UPF saturation — Alert on CPU spikes, RTT inflation, packet loss, log bursts, and UDP/2152 anomalies for hosts running open5gs-upfd. This will not prevent exploitation, but it will keep a partial degradation event from lingering as a mystery performance issue.
5. Track upstream for a fix — As of 2026-05-29 I did not find a patched upstream release beyond 2.7.7. Keep the issue on exception tracking and be ready to validate and deploy the first authoritative vendor fix within the MEDIUM remediation window once it exists.

Run this on the target Linux host that provides the Open5GS UPF role, either on the bare host or inside the container/VM image you actually deploy. Invoke it as bash check-open5gs-cve-2026-8187.sh; root is helpful but not strictly required if your package manager metadata is readable. It checks for an installed Open5GS package or UPF binary and reports VULNERABLE, PATCHED, or UNKNOWN based on whether the detectable version is <= 2.7.7.

#!/usr/bin/env bash
# check-open5gs-cve-2026-8187.sh
# Detect likely exposure to CVE-2026-8187 on Linux hosts running Open5GS UPF.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_FIXED="2.7.7"
found_version=""
found_source=""

normalize_version() {
  # Strip distro/package suffixes while keeping dotted semantic core.
  # Examples: 2.7.7-1 -> 2.7.7 ; 2.7.7+git -> 2.7.7
  echo "$1" | sed -E 's/^([^0-9]*)([0-9]+(\.[0-9]+){1,3}).*$/\2/'
}

version_le() {
  # returns 0 if $1 <= $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

# 1) Package manager checks
if have_cmd dpkg-query; then
  if dpkg-query -W -f='${Version}\n' open5gs >/dev/null 2>&1; then
    raw_ver="$(dpkg-query -W -f='${Version}\n' open5gs 2>/dev/null | head -n1)"
    found_version="$(normalize_version "$raw_ver")"
    found_source="dpkg:open5gs"
  fi
fi

if [ -z "$found_version" ] && have_cmd rpm; then
  if rpm -q --qf '%{VERSION}\n' open5gs >/dev/null 2>&1; then
    raw_ver="$(rpm -q --qf '%{VERSION}\n' open5gs 2>/dev/null | head -n1)"
    found_version="$(normalize_version "$raw_ver")"
    found_source="rpm:open5gs"
  fi
fi

# 2) Binary existence / service hints
upf_bin=""
for candidate in /usr/bin/open5gs-upfd /usr/sbin/open5gs-upfd /usr/local/bin/open5gs-upfd /usr/local/sbin/open5gs-upfd; do
  if [ -x "$candidate" ]; then
    upf_bin="$candidate"
    break
  fi
done

if [ -z "$found_version" ] && [ -n "$upf_bin" ]; then
  # Some builds may embed a version string; best-effort only.
  raw_ver="$(strings "$upf_bin" 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | sort -V | tail -n1)"
  if [ -n "$raw_ver" ]; then
    found_version="$(normalize_version "$raw_ver")"
    found_source="binary:$upf_bin"
  fi
fi

# 3) If no Open5GS footprint at all, UNKNOWN rather than PATCHED.
if [ -z "$found_version" ] && [ -z "$upf_bin" ]; then
  echo "UNKNOWN: Open5GS package/version not detected on this host"
  exit 2
fi

# 4) If UPF binary exists but version is unknown, keep UNKNOWN.
if [ -n "$upf_bin" ] && [ -z "$found_version" ]; then
  echo "UNKNOWN: open5gs-upfd present at $upf_bin but version could not be determined"
  exit 2
fi

# 5) Compare version threshold.
if version_le "$found_version" "$TARGET_FIXED"; then
  echo "VULNERABLE: detected Open5GS $found_version via $found_source (CVE-2026-8187 affects <= $TARGET_FIXED)"
  exit 1
fi

echo "PATCHED: detected Open5GS $found_version via $found_source (> $TARGET_FIXED)"
exit 0

Sources

1. NVD entry for CVE-2026-8187
2. Open5GS issue #4492 public reproduction details
3. Open5GS project site
4. Open5GS v2.7.7 release page
5. VulDB summary for CVE-2026-8187
6. CISA Known Exploited Vulnerabilities catalog
7. FIRST EPSS data and stats
8. Ubuntu CVE tracker entry