GHSA-44qj-cghf-9p97 is a high-severity (CVSS 7.5) Missing Authentication vulnerability in github.com/free5gc/smf. No vendor fix is recorded yet; mitigation options are listed below.
free5GC's SMF UPI POST /upi/v1/upNodesLinks exits the SMF process on overlapping UE pools (unauthenticated, reachable Fatalf)
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-44qj-cghf-9p97.
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-44qj-cghf-9p97 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 378,567 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/smfReal-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 SMF mounts the UPI management route group without inbound OAuth2 middleware (same root cause as free5gc/free5gc#887). The POST /upi/v1/upNodesLinks create-or-update handler accepts attacker-controlled JSON and passes it directly into UpNodesFromConfiguration(), which calls logger.InitLog.Fatalf(...) on several validation failures. One confirmed path is the UE-IP-pool overlap check: a single unauthenticated POST that adds a new UPF whose pool overlaps an existing UPF terminates the entire SMF process (docker ps shows Exited (1)), not just the goroutine. This is a stronger sink than free5gc/free5gc#905: that one panics inside the request goroutine and Gin recovers; this one calls Fatalf which is os.Exit(1)-equivalent and kills the whole SMF process, dropping all of SMF's SBI surface (PDU-session establishment, UE policy lookups, etc.) until the process is restarted.
Details
Validated against the SMF container in the official Docker compose lab.
- Source repo tag:
v4.2.1 - Running Docker image:
free5gc/smf:v4.2.1 - Runtime SMF commit:
8385c00a - Docker validation date: 2026-03-22 local (container log timestamp
2026-03-21T23:47:07Z) - SMF endpoint:
http://10.100.200.6:8000
The broader UPI auth gap (#887) lets the unauthenticated POST reach the create/update handler. From there:
Vulnerable handler dispatches into topology parsing:
POST /upi/v1/upNodesLinks
-> UpNodesFromConfiguration()
-> isOverlap(allUEIPPools)
-> logger.InitLog.Fatalf("overlap cidr value between UPFs")
Code evidence (paths in free5gc/smf):
- UPI group mounted WITHOUT auth middleware (preconditions for unauthenticated reachability):
NFs/smf/internal/sbi/server.go:76NFs/smf/internal/sbi/server.go:78
- Create-or-update handler accepts attacker JSON and forwards it to
UpNodesFromConfiguration():NFs/smf/internal/sbi/api_upi.go:60NFs/smf/internal/sbi/api_upi.go:72
- Pool parsing (input from attacker JSON):
NFs/smf/internal/context/user_plane_information.go:413
- Overlap check that calls
Fatalf:NFs/smf/internal/context/user_plane_information.go:479
The same unauthenticated POST path also reaches sibling Fatalf calls for invalid-pool and static-pool-exclusion failures, so this is not a one-off code smell -- it is a class of attacker-reachable Fatalf call sites on a single unauthenticated handler:
NFs/smf/internal/context/user_plane_information.go:416NFs/smf/internal/context/user_plane_information.go:424NFs/smf/internal/context/user_plane_information.go:430
PoC
Reproduced end-to-end against the running SMF at http://10.100.200.6:8000.
- Trigger: unauthenticated POST that adds a UPF with a UE pool overlapping the default UPF (
10.60.0.0/16):
curl -i -X POST http://10.100.200.6:8000/upi/v1/upNodesLinks \
-H 'Content-Type: application/json' \
--data '{"links":[{"A":"gNB1","B":"UPF-OVERLAP-20260322"}],"upNodes":{"UPF-OVERLAP-20260322":{"type":"UPF","nodeID":"198.51.100.20","addr":"198.51.100.20","sNssaiUpfInfos":[{"sNssai":{"sst":1,"sd":"010203"},"dnnUpfInfoList":[{"dnn":"internet","pools":[{"cidr":"10.60.0.0/16"}]}]}]}}}'
Client-side observation (server died mid-request, no HTTP response written):
curl: (52) Empty reply from server
- Confirm the SMF container exited:
docker ps -a --filter name=smf --format '{{.Names}}\t{{.Status}}'
smf Exited (1) 9 seconds ago
- SMF container logs (
docker logs --tail 80 smf) show theFATAline that terminated the process:
[FATA][SMF][Init] overlap cidr value between UPFs
Impact
Unauthenticated process-kill DoS on the SMF management plane.
- Missing inbound authentication (CWE-306) and authorization (CWE-862) on the
UPIroute group makes the trigger reachable to any off-path network attacker who can reach SMF on the SBI -- no token, no UE state needed. The same-instancensmf-oamreturning401(see free5gc/free5gc#887) proves OAuth middleware is wired in for other SMF route groups and only missing on UPI. - Reachable assertion / fail-fast (CWE-617): topology parsing calls
logger.InitLog.Fatalf(...)on attacker-influenced validation failures.Fatalfisos.Exit(1)-equivalent -- it skips Gin's recovery, the deferred handlers, and kills the whole SMF process. This is materially worse than the related panic-DoS in free5gc/free5gc#905, which Gin recovers from at the goroutine level.
Any party that can reach SMF on the SBI can:
- Send one unauthenticated POST with an overlapping UE pool and immediately terminate the SMF process, dropping all of SMF's SBI surface (PDU-session establishment, UE policy interactions) until SMF is restarted.
- Repeat the trigger after every restart to sustain the outage.
- Use sibling
Fatalfpaths (invalid-pool, static-pool exclusion) to sustain the same DoS even if the overlap check is hardened in isolation, because the underlying defect is usingFatalffor request-time validation on an unauthenticated handler.
No Confidentiality impact (the crash returns no data to the attacker). No persistent Integrity impact (the topology updates are in-memory and are lost when SMF dies). The whole impact concentrates in Availability: complete loss of SMF service via a single unauthenticated request.
Affected: free5gc v4.2.1.
Upstream issue: https://github.com/free5gc/free5gc/issues/906 Upstream fix: https://github.com/free5gc/smf/pull/203
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/free5gc/smf | 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/smf, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of github.com/free5gc/smf has shipped for GHSA-44qj-cghf-9p97 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-44qj-cghf-9p97 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-44qj-cghf-9p97. 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-44qj-cghf-9p97 in your dependencies?
O3 Security finds GHSA-44qj-cghf-9p97 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.