Unauthenticated NEF PFD Management API—Authentication Bypass in free5GC

Vulnerability Description

free5GC's Network Exposure Function (NEF) fails to enforce inbound OAuth2/bearer-token authorization on the nnef-pfdmanagement route group. The vulnerability is a missing authentication middleware at the routing layer (sbi/server.go:56), not a cryptographic or token-validation flaw. The nnef-pfdmanagement group is declared in the runtime ServiceList and advertises OAuth2 protection (receive from NRF: true), but no authentication middleware is applied during route registration. Consequently, an unauthenticated network attacker who can reach NEF on the Service-Based Interface (SBI) can issue requests with arbitrary or forged bearer tokens to:

• Read PFD application metadata via GET /applications and GET /applications/{appID}
• Manipulate PFD change-notification subscriptions via POST /subscriptions and DELETE /subscriptions/{subID}

All operations execute against UDR-backed persistent state, meaning attackers can exfiltrate application data and disrupt notification flows.

PoC Significance

This PoC is highly significant because it:

1. Proves structural failure, not an edge case—the entire route group lacks auth middleware.
2. Affects production deployments: Unlike OAM and traffic-influence route groups (known to be unprotected and undeclared), nnef-pfdmanagement IS in the production ServiceList and operators expect it to be protected.
3. Requires low preconditions: An attacker needs only network reach to NEF's SBI port and a fabricated bearer token (e.g., Authorization: Bearer invalid-token)—no cryptographic material or valid credentials required.
4. Validated in official container (v4.2.0 at commit 5ce35eab on 2026-03-11), confirming reproducibility in standard deployments.

Detection Guidance

Log Indicators:

• Requests to /nnef-pfdmanagement/v1/applications or /nnef-pfdmanagement/v1/subscriptions with missing or malformed Authorization headers.
• POST/DELETE operations to subscription endpoints from unexpected source IPs or with non-NRF user-agent patterns.
• Repeated GET /applications requests returning full PFD records in short time windows.
• Audit logs showing subscription modifications without corresponding NRF outbound calls.

SBI-Level Signatures:

• HTTP requests to NEF port targeting paths matching /nnef-pfdmanagement/v1/(applications|subscriptions).* where Authorization header is absent, malformed, or token format is invalid (e.g., base64 decode fails).

Network-Level:

• Monitor NEF SBI ingress for clients outside the expected NRF/UDR peer list accessing these routes.

Mitigation Steps

1. Immediate (Workaround):

   • Deploy network-level access controls: restrict SBI connectivity to NEF to only authorized NRF instances (firewall rules, mTLS enforcement).
   • Implement reverse-proxy authentication (e.g., Envoy, nginx) in front of NEF to enforce OAuth2 token validation before reaching the service.

2. Short-term (Code Patch):

   • Apply the upstream fix (pending release) that adds auth middleware to the nnef-pfdmanagement route group registration in sbi/server.go:56.
   • Upgrade to a patched free5GC version once available.

3. Configuration:

   • Verify NEF OAuth2 settings are correctly configured to receive and validate tokens from NRF.
   • Enable SBI mutual TLS (mTLS) if supported in your deployment.

Risk Assessment

Likelihood of Exploitation: High

• The vulnerability requires only network access to NEF and trivial request crafting; no exploit code, kernel-level primitives, or sophisticated tooling needed.
• Attackers can enumerate and read PFD application data (e.g., service descriptions, subscriber preferences) and disrupt operations.

Threat Actor Interest: High

• State-sponsored and cybercriminal groups targeting 5G infrastructure are likely to prioritize SBI API flaws that bypass authentication.
• PFD data leakage could support subscriber profiling, service disruption, or lateral movement into UDR/upstream services.

Impact if Exploited:

• Confidentiality breach: Exposure of application metadata and subscriber policy information.
• Integrity compromise: Unauthorized creation/deletion of subscriptions leads to notification disruption and potential DoS.
• Operational disruption: 5G core signaling plane may become unstable if subscriptions are maliciously modified.