GHSA-wr8j-6chw-gm6p is a high-severity (CVSS 7.5) vulnerability in github.com/free5gc/pcf. O3 Security confirms whether GHSA-wr8j-6chw-gm6p is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
free5GC's PCF npcf-smpolicycontrol POST /sm-policies panics on downstream UDR/OpenAPI 404 via nil pointer dereference
Real-World Exposure
github.com/free5gc/pcfReal-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 PCF POST /npcf-smpolicycontrol/v1/sm-policies handler (HandleCreateSmPolicyRequest) panics with a nil-pointer dereference when a downstream OpenAPI consumer call (UDR lookup) returns 404 Not Found and the consumer wrapper returns err != nil together with a nil response struct. The handler logs the OpenAPI error and continues executing instead of returning, then dereferences the nil response struct on a subsequent line and panics. Gin recovery converts the panic into HTTP 500, so a single attacker-shaped POST returns 500 instead of a clean 4xx whenever the downstream lookup fails. The PCF process keeps running.
The trigger is a single POST containing input that causes the downstream UDR lookup to fail (e.g. an unknown DNN). In v4.2.1 this endpoint is also reachable WITHOUT an Authorization header because the PCF Npcf_SMPolicyControl route group is mounted without inbound auth middleware (see free5gc/free5gc#844). So in the validation lab the trigger is fully unauthenticated.
Details
Validated against the PCF container in the official Docker compose lab.
- free5GC version:
v4.1.0(originally reported on v4.1.0; same defect present in v4.2.1) - PCF endpoint:
http://10.100.200.9:8000
Vulnerable handler path (paraphrased from the captured stack trace):
[INFO][PCF][SMpolicy] Handle CreateSmPolicy
[ERRO][PCF][Consumer] openapi error: 404, Not Found
[ERRO][PCF][GIN] panic: runtime error: invalid memory address or nil pointer dereference
github.com/free5gc/pcf/internal/sbi/processor.(*Processor).HandleCreateSmPolicyRequest
/go/src/free5gc/NFs/pcf/internal/sbi/processor/smpolicy.go:82 +0x562
github.com/free5gc/pcf/internal/sbi.(*Server).HTTPCreateSMPolicy
/go/src/free5gc/NFs/pcf/internal/sbi/api_smpolicy.go:86 +0x405
The handler's UDR-failure branch logs the OpenAPI error but does not return; the next line dereferences the nil response struct.
Code evidence (paths in free5gc/pcf):
- Panic site:
NFs/pcf/internal/sbi/processor/smpolicy.go:82
- Route dispatch:
NFs/pcf/internal/sbi/api_smpolicy.go:86
PoC
Reproduced end-to-end against the running PCF at http://10.100.200.9:8000.
Send a single POST whose dnn is unknown to UDR -- this drives the downstream OpenAPI call to return 404 Not Found, which then triggers the nil-deref panic:
curl -sS -X POST 'http://10.100.200.9:8000/npcf-smpolicycontrol/v1/sm-policies' \
-H 'Content-Type: application/json' \
-d '{
"supi":"imsi-208930000000003",
"pduSessionId":1,
"dnn":"internet-bad",
"sliceInfo":{"sst":1,"sd":"010203"},
"servingNetwork":{"mcc":"208","mnc":"93"},
"accessType":"3GPP_ACCESS",
"notificationUri":"http://smf.free5gc.org:8000/npcf-smpolicycontrol/v1/notify"
}'
Observed response: HTTP 500 Internal Server Error with empty body.
PCF container logs show:
[INFO][PCF][SMpolicy] Handle CreateSmPolicy
[ERRO][PCF][Consumer] openapi error: 404, Not Found
[ERRO][PCF][GIN] panic: runtime error: invalid memory address or nil pointer dereference
...HandleCreateSmPolicyRequest at smpolicy.go:82...
The Gin recovery middleware catches the panic (the captured stack trace runs inside ginRecover.func2.1), so the PCF process keeps serving other requests; the realized impact is per-request HTTP 500 on this endpoint whenever the downstream lookup fails.
Impact
NULL pointer dereference (CWE-476) caused by improper handling of an exceptional branch (CWE-754): the UDR-failure branch logs the OpenAPI error but does not return, then dereferences the nil response struct. The intended behavior is to return a controlled 4xx/5xx ProblemDetails and stop processing.
Gin recovery catches the panic, so the PCF process is NOT killed and other endpoints continue serving. The realized impact is per-request: any unauthenticated POST that drives the downstream UDR lookup to a 404 returns HTTP 500 (with empty body and a stack trace in PCF logs) instead of a controlled error response.
No Confidentiality impact (the response is 500 with empty body). No persistent Integrity impact (the panic happens before any state mutation). Availability impact is limited to per-request degradation. The endpoint remains reachable to unauthenticated attackers via the route-group auth gap separately tracked in free5gc/free5gc#844.
Affected: free5gc v4.2.1 (originally reported against v4.1.0; same defect present).
Upstream issue: https://github.com/free5gc/free5gc/issues/803 Upstream fix: https://github.com/free5gc/pcf/pull/62
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/free5gc/pcf | all versions | 1.4.2 |
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/pcf. 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.
Fix
Update github.com/free5gc/pcf to 1.4.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wr8j-6chw-gm6p is resolved across your whole dependency graph.
Workarounds
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-wr8j-6chw-gm6p 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-wr8j-6chw-gm6p. 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-wr8j-6chw-gm6p in your dependencies?
O3 detects GHSA-wr8j-6chw-gm6p across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.