Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-44327

CVE-2026-44327: free5GC Authentication Bypass Vulnerability

CVE-2026-44327 is an authentication bypass flaw in free5GC's NEF component that allows unauthorized access to OAM routes. This post covers technical details, affected versions, security impact, and mitigation.

Published:

CVE-2026-44327 Overview

CVE-2026-44327 is a missing authentication vulnerability [CWE-306] in free5GC, an open-source implementation of the 5G core network. The Network Exposure Function (NEF) mounts the nnef-oam route group without inbound OAuth2 or bearer-token authorization middleware. A network attacker reaching NEF on the Service-Based Interface (SBI) can invoke Operations, Administration, and Maintenance (OAM) endpoints without an Authorization header and receive 200 OK responses. The defect is scoped to the entire route group, meaning every future OAM handler added to the group inherits the missing auth boundary. The issue affects free5GC versions prior to 4.2.2.

Critical Impact

Unauthenticated attackers with SBI network reach can invoke NEF OAM operations, bypassing the OAuth2 trust boundary expected in 5G core deployments.

Affected Products

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

Discovery Timeline

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

Technical Details for CVE-2026-44327

Vulnerability Analysis

The NEF is the 5G core component that exposes network capabilities to external Application Functions (AFs). Within the 3GPP Service-Based Architecture (SBA), all SBI traffic between Network Functions (NFs) is expected to be protected by OAuth2 access tokens. free5GC's NEF registers the nnef-oam route group on its HTTP router without attaching the OAuth2 bearer-token validation middleware that protects other NEF route groups.

Any HTTP client able to reach the NEF SBI endpoint can send a request to an OAM route with no Authorization header and the handler executes. The current OAM handler is a stub returning null, so direct data exposure is limited today. However, the structural defect persists at the route-group level. Any OAM operation added to nnef-oam in future releases will be exposed by default without authentication.

Root Cause

The root cause is missing authentication middleware registration on a route group [CWE-306]. The NEF router configuration mounts the OAM routes outside the scope of the inbound OAuth2 enforcement chain. Authorization is treated as a per-route concern rather than a default-deny baseline, so omission becomes silent rather than failing closed.

Attack Vector

The attack vector is network-based and requires no authentication, no user interaction, and low complexity. An attacker who can route TCP traffic to the NEF SBI listener sends an unauthenticated HTTP request to a path under the nnef-oam route group. The server responds 200 OK. In hardened deployments the SBI is segregated, but flat topologies, lab environments, and misconfigured Kubernetes service exposures place the NEF within reach of broader networks. The scope-changed CVSS rating reflects that NEF compromise crosses the trust boundary between the 5G core and external AFs.

The vulnerability mechanism is described in the GitHub Security Advisory GHSA-cmpj-2x3g-m7g3 and tracked in GitHub Issue #861. No verified proof-of-concept code is published.

Detection Methods for CVE-2026-44327

Indicators of Compromise

  • HTTP requests to NEF SBI paths under /nnef-oam/ that lack an Authorization: Bearer header
  • 200 OK responses from NEF OAM routes originating from source IPs outside the expected NF peer set
  • Access log entries showing OAM route invocations from clients that have not completed NRF-mediated OAuth2 token acquisition

Detection Strategies

  • Inspect NEF access logs for requests to the nnef-oam route group and correlate against the presence and validity of bearer tokens
  • Run authenticated configuration audits against running NEF instances to confirm middleware is bound to every route group
  • Monitor SBI east-west traffic for HTTP requests to NEF that omit OAuth2 headers, which should never occur in a compliant SBA deployment

Monitoring Recommendations

  • Forward NEF and SBI gateway logs to a centralized SIEM for query against unauthenticated access patterns
  • Alert on any non-2xx-to-2xx transition for OAM endpoints after patching, indicating residual misconfiguration
  • Track free5GC version inventory across clusters and flag any NEF pod running a release earlier than 4.2.2

How to Mitigate CVE-2026-44327

Immediate Actions Required

  • Upgrade free5GC to version 4.2.2 or later, which adds OAuth2 enforcement to the nnef-oam route group
  • Restrict NEF SBI network exposure to the 5G core service mesh and authorized AFs only, using network policies or service mesh authorization
  • Audit all NEF route group registrations to confirm authentication middleware is applied by default

Patch Information

The fix is delivered in free5GC 4.2.2. The corresponding NEF change is published in GitHub NEF Pull Request #23, which attaches the OAuth2 bearer-token middleware to the OAM route group so that unauthenticated requests are rejected before reaching any handler. Operators should redeploy NEF pods or binaries from the patched release and verify the running version after rollout.

Workarounds

  • Block external access to the NEF SBI listener using Kubernetes NetworkPolicy, firewall rules, or service mesh AuthorizationPolicy until the upgrade is applied
  • Place an authenticating reverse proxy in front of NEF that rejects requests lacking a valid OAuth2 bearer token
  • Disable or remove the nnef-oam route registration in deployments that do not require OAM functionality
bash
# Example Kubernetes NetworkPolicy restricting NEF SBI ingress to core NFs
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: nef-sbi-restrict
  namespace: free5gc
spec:
  podSelector:
    matchLabels:
      nf: nef
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: 5gc-nf
      ports:
        - protocol: TCP
          port: 8000

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.