CVE-2026-44315: free5GC NEF Auth Bypass Vulnerability

CVE-2026-44315 Overview

CVE-2026-44315 is a missing authorization vulnerability [CWE-862] in free5GC, an open-source implementation of the 5G core network. Versions prior to 4.2.2 mount the 3gpp-pfd-management API on the Network Exposure Function (NEF) without inbound OAuth2 or bearer-token authorization checks. A network attacker who can reach NEF on the Service Based Interface (SBI) can create, read, and delete Packet Flow Description (PFD) management transaction state using a forged or arbitrary bearer token. The route group also remains reachable even when operators remove it from the running ServiceList configuration, leaving deployments exposed despite intended service hardening.

Critical Impact
An unauthenticated network attacker can manipulate PFD-management transaction state on the 5G core, undermining traffic policy integrity and core network availability.

Affected Products

free5GC versions prior to 4.2.2
free5GC NEF (Network Exposure Function) component
Deployments exposing the SBI to untrusted networks

Discovery Timeline

2026-05-27 - CVE-2026-44315 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-44315

Vulnerability Analysis

The vulnerability resides in the free5GC NEF component, which exposes the 3GPP PFD management API over the SBI. The route handlers are mounted without any inbound authorization middleware. As a result, the server accepts requests carrying any Authorization: Bearer value, including syntactically invalid or entirely fabricated tokens such as Bearer not-a-real-token.

An attacker who can reach the NEF over the network can issue requests against the PFD management endpoints to create, retrieve, and delete transaction state. This affects PFD records that govern how the User Plane Function (UPF) identifies application traffic, which means manipulation can disrupt traffic classification and policy enforcement across the 5G core.

A secondary issue compounds the exposure. The PFD management route group is registered at startup regardless of whether the running configuration's ServiceList declares the service. Operators who believe they have disabled the API through configuration remain reachable on the network. See the GitHub Security Advisory GHSA-5f62-53r8-qrqf for further details.

Root Cause

The NEF service registers the 3gpp-pfd-management routes without applying the OAuth2 bearer-token validation middleware required by 3GPP SBI specifications. The configuration-driven service gating is also bypassed because route registration is unconditional.

Attack Vector

Exploitation requires only network reachability to the NEF SBI endpoint. No valid credentials, user interaction, or prior privileges are needed. The attacker sends HTTP requests with an arbitrary bearer token to the PFD management endpoints and receives full create, read, and delete access to transaction state.

No verified public exploit code is available. Refer to the GitHub Issue Report and Pull Request #23 for the technical fix details.

Detection Methods for CVE-2026-44315

Indicators of Compromise

HTTP requests to NEF PFD management endpoints (/3gpp-pfd-management/v1/...) carrying malformed, expired, or unrecognized bearer tokens.
Unexpected POST, PUT, or DELETE operations against PFD transactions originating from network sources outside the trusted SBI plane.
PFD transaction state changes that do not correlate with authorized Application Function (AF) activity logged by the operator.

Detection Strategies

Inspect NEF access logs for requests where the Authorization header is present but the token does not match issued OAuth2 credentials.
Compare the active NEF route table against the configured ServiceList to identify route groups registered without configuration backing.
Correlate PFD transaction lifecycle events with authorized AF sessions to detect orphaned or attacker-driven transactions.

Monitoring Recommendations

Forward NEF and SBI gateway logs to a centralized analytics platform for query and alerting on anomalous PFD API usage.
Alert on any successful PFD management API response where bearer token validation was skipped or returned non-standard claims.
Monitor north-south and east-west traffic to NEF for sources outside the expected AF and NRF peer list.

How to Mitigate CVE-2026-44315

Immediate Actions Required

Upgrade free5GC to version 4.2.2 or later, which adds inbound bearer-token authorization to the PFD management routes.
Restrict network reachability to the NEF SBI to only trusted Network Functions and AFs via network policy or service mesh controls.
Audit existing PFD transaction state for unauthorized entries created prior to remediation and remove any that are not attributable to legitimate AFs.

Patch Information

The issue is fixed in free5GC 4.2.2. The corrective change is tracked in GitHub Pull Request #23 on the free5GC NEF repository, which adds inbound OAuth2/bearer-token authorization and corrects route registration so it honors the ServiceList configuration.

Workarounds

Place an authenticating reverse proxy or service mesh sidecar in front of the NEF that enforces OAuth2 bearer validation before forwarding requests.
Apply Kubernetes NetworkPolicies or firewall rules that limit ingress to the NEF SBI port to the IP ranges of legitimate 5G Network Functions only.
Disable or block external routing to the 3gpp-pfd-management URI path at the ingress layer until the upgrade to 4.2.2 is complete.

bash

# Example: restrict ingress to free5GC NEF SBI using a Kubernetes NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nef-sbi-restrict
  namespace: free5gc
spec:
  podSelector:
    matchLabels:
      app: free5gc-nef
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              nf-role: af
        - podSelector:
            matchLabels:
              nf-role: nrf
      ports:
        - protocol: TCP
          port: 8000