GHSA-rxrq-fv76-26pr: free5GC's NEF crashes via logger.Fatal on PFD notification delivery failure (attacker-controlled notifyUri)
Summaryfree5GC's NEF terminates the entire process when a stored PFD-subscription `notifyUri` cannot be reached. In `PfdChangeNotifier.FlushNotifications()`, the notifier calls `NnefPFDmanagementNotify(...)` and on any delivery error invokes `logger.PFDManageLog.Fatal(err)`, which is `os.Exit(1)`-equivalent in Go. An attacker who can create a PFD subscription with an attacker-chosen `notifyUri` and then trigger a PFD change can deterministically kill NEF on the asynchronous delivery attempt -- the process exits with status `1`, dropping NEF's entire SBI surface until restart. This is materially worse than a per-request panic-DoS (Gin recovery does not catch `Fatal`).The trigger uses three POSTs that are reachable without an `Authorization` header in v4.2.1, because the underlying NEF SBI route groups themselves are mounted without inbound auth middleware (see free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the lab the entire chain is unauthenticated end-to-end. This advisory is scoped to the `Fatal`-on-delivery-failure code defect; the auth-bypass primitives are tracked separately in the upstream issues above.DetailsValidated against the NEF container in the official Docker compose lab.Source repo tag: `v4.2.1`Running Docker image: `free5gc/nef:v4.2.1`Runtime NEF commit: `5ce35eab`Docker validation date: 2026-03-20 (container log timestamp `2026-03-20T16:00:03Z`)NEF endpoint: `http://10.100.200.19:8000`Vulnerable notifier path:The failing branch is reached whenever NEF's outbound POST to the subscriber's `notifyUri` returns an error (connection refused, DNS failure, TLS error, timeout, etc.). The delivery happens asynchronously after the PFD-management transaction is accepted, so the triggering HTTP request (the PFD change) returns `201 Created` and only then does NEF die.Code evidence (paths in `free5gc/nef`):Notifier dispatch:`NFs/nef/internal/sbi/notifier/pfd_notifier.go:135`Fatal call site (process exit):`NFs/nef/internal/sbi/notifier/pfd_notifier.go:142`PoCReproduced end-to-end against the running NEF at `http://10.100.200.19:8000` -- three unauthenticated POSTs, the third one indirectly triggers async notify -> Fatal -> process exit.Create an AF context (no Authorization header):Create a PFD subscription with an attacker-chosen unreachable callback (port 1 = always refused locally):Trigger a PFD change so NEF tries to deliver a notification to the bad URI:The PFD POST itself returns `201`, but immediately afterward NEF exits.Confirm the NEF container is dead (`exited`, `exit=1`):NEF container logs (`docker logs --since 2026-03-20T16:00:03Z nef`) show the `[FATA]` line that terminated the process:ImpactReachable assertion / fail-fast (CWE-617) inside an asynchronous notification delivery path, plus improper handling of an exceptional condition (CWE-755) (treating a transient outbound HTTP failure as fatal), plus missing input validation (CWE-20) on the attacker-supplied `notifyUri`. `logger.Fatal` is `os.Exit(1)`-equivalent in Go -- it skips Gin recovery, deferred cleanup, and connection draining; the whole NEF process terminates.In v4.2.1, the trigger chain is reachable without an `Authorization` header because the NEF route groups used in the chain are themselves mounted without inbound auth middleware (free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the validation lab any party that can reach NEF on the SBI can:Submit the three-step trigger anonymously and immediately terminate the NEF process.Repeat the trigger after every restart to sustain the outage.Pick any unreachable `notifyUri` (refused port, blackholed IP, DNS-NXDOMAIN, broken TLS) -- the failure branch is the same `Fatal`, so partial fixes that block one URI do not close the family.No Confidentiality impact (the failure returns no attacker-readable data). No persistent Integrity impact (NEF state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of NEF service via a single attacker-controlled notification target.Affected: free5gc v4.2.1.Upstream issue: https://github.com/free5gc/free5gc/issues/924
Upstream fix: https://github.com/free5gc/nef/pull/25
CVSS v3.1: 7.5