CVE-2026-44329 Overview
CVE-2026-44329 is a missing authentication vulnerability [CWE-306] in free5GC, an open-source implementation of the 5G core network. The Session Management Function (SMF) registers the User Plane Information (UPI) management route group without attaching OAuth2 or bearer-token authorization middleware. Any network attacker who can reach the SMF on the Service Based Interface (SBI) can invoke UPI endpoints without supplying an Authorization header. Researchers demonstrated unauthenticated read, write, and delete operations against /upi/v1/upNodesLinks in a Docker lab environment. The flaw affects free5GC versions prior to 4.2.2 and is fixed in release 4.2.2.
Critical Impact
Unauthenticated attackers reachable on the SBI can read, modify, and delete UP-node link topology managed by the SMF, enabling tampering with 5G core user-plane routing.
Affected Products
- free5GC core network releases prior to 4.2.2
- free5GC smf component exposing the UPI management API
- 5G core deployments exposing the SMF SBI to untrusted networks
Discovery Timeline
- 2026-05-27 - CVE-2026-44329 published to NVD
- 2026-05-27 - Last updated in NVD database
Technical Details for CVE-2026-44329
Vulnerability Analysis
The free5GC SMF exposes a UPI management API group used to enumerate and manipulate user-plane node links. In affected releases, this route group is registered in internal/sbi/server.go without the OAuth2 authorization check applied to other SBI service groups. Requests sent without any Authorization header reach the business handlers unfiltered. The exposure includes GET /upi/v1/upNodesLinks for enumeration, POST /upi/v1/upNodesLinks for creating attacker-controlled UP-node and link payloads, and DELETE /upi/v1/upNodesLinks/{nodeID} for removing topology entries. Tampering with these objects manipulates how the SMF perceives the user-plane topology, with downstream effects on session routing decisions for connected UEs.
Root Cause
The upiGroup router group was registered and populated with handlers via applyRoutes, but no middleware invoking util_oauth.NewRouterAuthorizationCheck was attached. Other SBI groups in the same server apply the OAuth2 check before reaching handler logic. The UPI group inherited no such enforcement, leaving the endpoints anonymous by default.
Attack Vector
An attacker with network reachability to the SMF SBI listener issues plain HTTP requests to /upi/v1/upNodesLinks without credentials. No authentication, token, or prior service registration is required. The attacker can enumerate existing UP-node links, inject new links pointing to attacker-controlled nodes, or delete legitimate entries to disrupt routing state.
// Source: https://github.com/free5gc/smf/commit/e23ce97565f285eb99eed153743c62bf4c767c6e
// Patch in internal/sbi/server.go attaching the OAuth2 check to upiGroup
applyRoutes(smfCallbackGroup, smfCallbackRoutes)
upiGroup := router.Group(factory.UpiUriPrefix)
+ upiAuthCheck := util_oauth.NewRouterAuthorizationCheck(models.ServiceName_NSMF_OAM)
+ upiGroup.Use(func(c *gin.Context) {
+ upiAuthCheck.Check(c, smf_context.GetSelf())
+ })
upiRoutes := s.getUPIRoutes()
applyRoutes(upiGroup, upiRoutes)
The patch wires NewRouterAuthorizationCheck for the NSMF_OAM service into the upiGroup so every UPI request is validated before reaching handlers.
Detection Methods for CVE-2026-44329
Indicators of Compromise
- HTTP requests to /upi/v1/upNodesLinks on the SMF SBI that lack an Authorization header.
- POST or DELETE requests to /upi/v1/upNodesLinks originating from sources that are not registered Network Functions in the 5G core.
- Unexpected UP-node entries or link mutations appearing in SMF state without a corresponding NF Repository Function (NRF) registration event.
Detection Strategies
- Inspect SMF access logs and Service Mesh telemetry for UPI URI prefix calls and flag those without bearer tokens.
- Correlate UPI topology changes with the identity of the calling NF; mismatches indicate unauthorized configuration writes.
- Deploy network-layer rules on the SBI to alert on UPI endpoint access from IP ranges outside the 5G control-plane subnet.
Monitoring Recommendations
- Capture and retain full SBI HTTP request metadata, including headers, for the SMF to enable retrospective hunting.
- Alert on any 4xx to 2xx transitions on /upi/v1/upNodesLinks after upgrading, which may indicate prior abuse attempts that now fail.
- Baseline the volume and source of legitimate UPI calls in operations workflows and alert on deviations.
How to Mitigate CVE-2026-44329
Immediate Actions Required
- Upgrade free5GC to version 4.2.2 or later, which adds the OAuth2 middleware to the upiGroup router.
- Restrict SMF SBI exposure to the 5G control-plane network and block UPI URI access from any other source.
- Audit existing UP-node link state in the SMF to identify and remove unauthorized entries before upgrading.
Patch Information
The fix is delivered in the smf component pull request free5gc/smf#197 and merged in commit e23ce97. It registers util_oauth.NewRouterAuthorizationCheck(models.ServiceName_NSMF_OAM) as middleware on the UPI router group so requests without a valid bearer token are rejected before handler execution. See the GitHub Security Advisory GHSA-3258-qmv8-frp3 for the full vendor statement and the issue discussion.
Workarounds
- Place an authenticating reverse proxy in front of the SMF SBI that rejects requests to /upi/v1/* lacking a valid OAuth2 bearer token.
- Apply network policies or firewall rules that drop inbound traffic to the UPI URI prefix from any source outside trusted OAM tooling.
- Disable or remove the UPI management routes in custom builds where the OAM API is not required for operations.
# Example NetworkPolicy snippet limiting SMF SBI ingress to the control-plane namespace
# (apply with kubectl after reviewing for your cluster topology)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: smf-sbi-restrict
namespace: free5gc
spec:
podSelector:
matchLabels:
nf: smf
ingress:
- from:
- namespaceSelector:
matchLabels:
role: 5g-control-plane
ports:
- protocol: TCP
port: 8000
policyTypes:
- Ingress
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

