CVE-2026-44329

free5GC · SMF (Session Management Function)

The free5GC SMF component improperly manages UPI route groups, allowing unauthenticated attackers to perform unauthorized read, write, and delete operations.

Executive summary

A critical authentication bypass in the free5GC SMF component allows an unauthenticated network attacker to perform unauthorized management operations on the 5G core network.

Vulnerability

The vulnerability stems from the SMF component mounting UPI management route groups without required OAuth2/bearer-token authorization middleware. This allows an unauthenticated attacker with network access to the Service-Based Architecture (SBI) to interact directly with UPI endpoints.

Business impact

The CVSS score of 10.0 signifies the highest level of risk, as it allows for unauthorized control over critical 5G network management functions. Exploitation could lead to severe network disruption, interception of communication, or total manipulation of user plane nodes, causing catastrophic service outages.

Remediation

Immediate Action: Update free5GC SMF to version 4.2.2 or later to implement required authorization middleware.

Proactive Monitoring: Audit network logs for unauthorized access attempts or suspicious traffic patterns directed at SBI endpoints and UPI management routes.

Compensating Controls: Implement strict network micro-segmentation to ensure only authorized components can communicate with the SMF service, effectively isolating it from untrusted network segments.

Exploitation status

Public Exploit Available: Yes

Analyst recommendation

This vulnerability is exceptionally severe due to the lack of any authentication requirements. Organizations utilizing free5GC must prioritize the update to version 4.2.2 to close this critical security gap and prevent unauthorized manipulation of core network infrastructure.

Deep Dive #2

Am I vulnerable, and what should I do?

Operational write-up published 2026-05-28. Detection rules are starter content — validate before deploying.

CVE-2026-44329 is a missing-authorization flaw in the free5GC SMF (Session Management Function). The SMF mounts its UPI management route group without the OAuth2/bearer-token middleware that protects the sibling interfaces on the same service, so any host that can reach the Service-Based Interface (SBI) can read, write, and delete user-plane topology entries with no credentials. NVD scores it 10.0. The fix shipped in free5GC 4.2.2.

Am I vulnerable?

Affected versions

Product	Vulnerable range	Fixed
free5GC SMF	All versions prior to 4.2.2 (≤ 4.2.1)	4.2.2

Any free5GC deployment whose SMF is built from a release before 4.2.2 — or from a latest/untagged image built before the fix merged on 2026-03-23 — exposes the unauthenticated UPI route group. The flaw is in the route wiring itself, so it is present regardless of how the network slice or UPF hardware is configured.

Diagnostic commands

All read-only. Run the version checks first; only use the network probe against a system you are authorized to test, and keep it to the GET shown — do not issue write/delete methods against production.

Kubernetes / containerized: kubectl get pods -n free5gc -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}' | grep -i smf. Vulnerable if the SMF image tag is earlier than the 4.2.2 release line, or an untagged/latest image built before 2026-03-23.
Docker host: docker ps --filter name=smf --format '{{.Image}}'. Vulnerable if the free5gc/smf tag predates 4.2.2.
Source / git deployment: git -C /path/to/free5gc describe --tags --always. Vulnerable if the tag/commit predates v4.2.2.
Live auth check (read-only): curl -s -o /dev/null -w '%{http_code}\n' http://<SMF-SBI-host>:<port>/upi/v1/upNodesLinks. An unauthenticated GET that returns 200 means the UPI group is unprotected and the deployment is vulnerable; a patched 4.2.2+ build returns 401 Unauthorized.

"Vulnerable" here means functional, not theoretical: if the UPI route group answers a token-less request with a 2xx, an attacker who can reach the SBI can manipulate user-plane topology.

Vulnerability

This is a missing-authorization bug — NVD classifies it as CWE-306 (Missing Authentication for Critical Function) and CWE-862 (Missing Authorization). free5GC implements the 3GPP Service-Based Architecture as a set of HTTP/2 REST services, and each network function is supposed to gate its management interfaces behind OAuth2 bearer-token checks negotiated through the NRF. The SMF does this correctly for its nsmf-oam route group. It does not do it for the UPI route group: that group is mounted with no inbound authorization middleware at all, so requests land directly on the business handlers.

The practical primitive is full unauthenticated CRUD over the SMF's view of the user-plane topology. An attacker reaching the SBI can read the current user-plane node and link inventory, inject attacker-controlled UPF and link entries, or delete named entries — all without presenting a token. The GitLab Advisory Database notes this is route-group-scoped and shares a root cause with a cluster of sibling UPI-interface issues (CVE-2026-44321, CVE-2026-44328), all tracing to the same absent middleware.

One scoring note worth flagging: NVD's published vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H. The 10.0 base score is driven by the changed scope plus high integrity and availability impact; the confidentiality metric is listed as Low despite the read access to topology data. The score is reported here as NVD published it. A functional proof-of-concept is referenced in the advisory; no exploit code is reproduced here.

Threat model

Who would exploit this: Reaching the SMF's SBI requires network access to an internal 5G core plane, not an internet-facing service, so the realistic operator is one who already holds a foothold on the core or an adjacent management network. The most likely categories are targeted intruders and initial-access brokers who have breached a private/enterprise 5G operator, malicious insiders or contractors with lab/testbed access, and state-aligned actors interested in telecom surveillance or disruption. Opportunistic mass exploitation is unlikely because the SBI is not normally exposed to the public internet.

What they're after:

Network disruption / denial of service against user-plane nodes and network slices
Subscriber user-plane traffic interception or redirection via topology poisoning
Lateral movement toward adjacent network functions and UPFs
Persistence through manipulated user-plane node configuration

Attack chain: An attacker with SBI network access sends token-less requests to the SMF's /upi/v1/ route group, which lacks the OAuth2 middleware applied to sibling interfaces. The requests reach the SMF handlers directly, letting the attacker read the current user-plane node and link topology, inject attacker-controlled UPF and link entries, or delete existing named entries. Those changes alter how the SMF models the user-plane topology and selects nodes for sessions.

Blast radius: Control over UPI management lets an attacker rewrite the topology the SMF relies on — steering subscriber sessions toward attacker-introduced UPF entries (enabling interception or redirection) or removing legitimate nodes to deny service. Deleting or corrupting entries can disrupt specific network slices and the sessions that depend on them, and in affected versions the delete path can additionally trigger a process-level fault in the SMF. Impact is scoped to the user plane and the NFs the SMF coordinates with rather than the entire core, but it directly affects subscriber connectivity and data confidentiality for the served deployment. No public in-the-wild exploitation or named attribution exists as of 2026-05-28.

Mitigation

Patch

Product	Fixed version	Reference
free5GC SMF	4.2.2	free5gc/smf PR #197 (commit `e23ce97`), upstream issue #887

Upgrade free5GC to 4.2.2 or later. The release adds the OAuth2/bearer-token authorization check to the UPI route group, bringing it to parity with the already-protected nsmf-oam group; unauthorized requests then receive 401 Unauthorized.

Code mitigation

If you maintain a fork or build from source, the canonical fix applies the existing authorization checker to the UPI group in NFs/smf/internal/sbi/server.go:

Apply OAuth2 authorization middleware to the UPI route group (free5gc/smf PR #197):

upiAuthCheck := util_oauth.NewRouterAuthorizationCheck(models.ServiceName_NSMF_OAM)
upiGroup.Use(func(c *gin.Context) {
  upiAuthCheck.Check(c, smf_context.GetSelf())
})

Compensating controls

Where an immediate upgrade is not possible, restrict reachability to the SMF SBI so untrusted hosts cannot reach the UPI endpoints (/upi/v1/*). Enforce SBI micro-segmentation and network policy so only authorized NFs can talk to the SMF — this buys time but is not a fix, since the route group still accepts any request that reaches it. Audit core-network logs for unauthenticated access to SBI and UPI management routes in the meantime.

Detection (starter rules — validate before deploying)

These rules are AI-generated starter content. Test against your own telemetry and tune falsepositives before deploying to production.

Network and log signals

HTTP/2 requests to the SMF SBI port that return 2xx for UPI management paths (e.g. paths containing /upi) while carrying no Authorization: Bearer header — successful access without an OAuth2 token is the core signal.
Write/mutation methods (PUT, POST, PATCH, DELETE) to SMF/UPI management routes from source IPs that are not the NRF or an expected peer NF (AMF/PCF/UDM/UPF) inside the SBI subnet.
UPI management endpoint access from source IPs outside the known core control-plane CIDR, regardless of method.
A source IP successfully invoking SMF UPI management APIs with no preceding NRF access-token request (Nnrf_AccessToken) — a token-less host behaving like an authenticated NF.
Clustered DELETE/PUT bursts against management routes returning 2xx, indicating unauthorized read/write/delete enumeration.

Sigma

title: free5GC SMF UPI Management Endpoint Access Without OAuth2 Bearer Token (CVE-2026-44329)
id: 7f3c1a2b-9d4e-4f60-8a21-1c2d3e4f5a6b
status: experimental
description: |
  Detects successful (2xx) HTTP requests to free5GC SMF UPI management endpoints on the 5G Service-Based Interface (SBI) that lack an OAuth2 'Authorization: Bearer' header. free5GC prior to 4.2.2 mounts UPI management route groups without bearer-token authorization middleware, allowing an unauthenticated attacker with SBI network access to read/write/delete via the SMF management HTTP/2 REST API. AI-generated starter rule — validate in your environment before deploying.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-44329
author: CVE Brief (AI-generated starter rule)
date: 2026/05/28
tags:
  - attack.initial_access
  - attack.t1190
  - attack.privilege_escalation
logsource:
  category: webserver
  description: SBI HTTP access logs from the free5GC SMF (Gin) including request path, method, status code, source IP, and request Authorization header.
detection:
  selection_upi_path:
    cs-uri-stem|contains:
      - '/upi'
      - '/nupi'
      - '/smf/management'
      - '/upi-management'
  selection_success:
    sc-status:
      - 200
      - 201
      - 202
      - 204
  filter_has_bearer:
    cs-auth-header|contains: 'Bearer '
  condition: selection_upi_path and selection_success and not filter_has_bearer
fields:
  - c-ip
  - cs-method
  - cs-uri-stem
  - sc-status
  - cs-auth-header
falsepositives:
  - Legitimate internal NF-to-NF (e.g. NRF, AMF, PCF, UPF) calls misconfigured to run without OAuth2 tokens in lab or non-hardened deployments.
  - Health checks, liveness/readiness probes, or monitoring/scraping agents hitting management routes without a bearer token.
  - Local administrative tooling or CI/CD smoke tests on the management API from trusted hosts.
  - Load balancers or service meshes that strip/terminate the Authorization header before logging.
level: high

Rule notes

The Sigma rule fires on 2xx responses to UPI/SMF management paths that lack an Authorization: Bearer header, which directly mirrors the missing-middleware flaw. It depends on SBI HTTP access logs capturing both the URI and the Authorization header (often not logged by default) and on tuning the path list to the deployment's actual route prefixes. No YARA rule is provided: this is a network/auth-logic flaw with no reliable static file or fixed payload signature, so a YARA rule would be noisy and low-value.