CVE-2026-44325 Overview
CVE-2026-44325 is a type confusion vulnerability in free5GC, an open-source implementation of the 5G core network. The flaw resides in the Network Repository Function (NRF) Service-Based Interface (SBI) endpoint POST /oauth2/token. An unauthenticated attacker can send a single crafted form-encoded request to remotely crash the request handler. The endpoint is repeatedly triggerable, allowing sustained denial of service against the 5G core. All versions prior to 4.2.2 are affected. The vulnerability is tracked under [CWE-20] Improper Input Validation.
Critical Impact
A single unauthenticated HTTP form request can panic the NRF /oauth2/token handler, enabling sustained remote denial of service against the 5G core network.
Affected Products
- free5GC versions prior to 4.2.2
- free5GC NRF component (NFs/nrf/internal/sbi/api_accesstoken.go)
- 5G core deployments using vulnerable free5GC NRF builds
Discovery Timeline
- 2026-05-27 - CVE-2026-44325 published to NVD
- 2026-05-27 - Last updated in NVD database
Technical Details for CVE-2026-44325
Vulnerability Analysis
The vulnerability sits in the NRF root SBI handler at NFs/nrf/internal/sbi/api_accesstoken.go. The handler iterates over the fields of models.NrfAccessTokenAccessTokenReq using Go reflection. It special-cases only plain string fields and the NrfNfManagementNfType field. Every other field name supplied by the client is treated as if its destination type were *models.PlmnId.
The handler parses the form value into a *models.PlmnId and then calls reflect.Value.Set() against the target struct field. When the destination field's real type is a slice, a different struct, or a primitive, the assignment is type-incompatible and the Go runtime panics. Gin's recovery middleware converts the panic into an HTTP 500 response, but the underlying handler goroutine is interrupted on every request. An attacker can replay the request indefinitely to keep the OAuth2 token endpoint unavailable.
Root Cause
The root cause is parser-level type confusion driven by unchecked reflection. The handler assumes every non-string, non-NfType field maps to models.PlmnId instead of validating each field's declared type before assignment. No authentication is required to reach the reflective code path.
Attack Vector
The attack is network-accessible and requires no privileges or user interaction. An adversary submits a single form-encoded POST request to /oauth2/token containing any field name from NrfAccessTokenAccessTokenReq whose underlying type is not string or NrfNfManagementNfType. The reflective Set call panics, the request returns HTTP 500, and the attacker repeats the request to maintain the disruption.
No verified exploit code is published. See the GitHub Security Advisory GHSA-f8qv-7x5w-qr48 and the upstream fix commit f7bc77d for full technical context.
Detection Methods for CVE-2026-44325
Indicators of Compromise
- Repeated HTTP 500 responses from the NRF /oauth2/token endpoint to unauthenticated clients.
- Go panic stack traces in NRF logs referencing reflect.Value.Set and api_accesstoken.go.
- Bursts of form-encoded POST /oauth2/token requests containing unexpected field names.
Detection Strategies
- Inspect NRF application logs for runtime error panics and Gin recovery middleware messages tied to the access token handler.
- Monitor reverse proxy or service mesh telemetry for elevated 5xx error rates on the NRF SBI /oauth2/token route.
- Correlate unauthenticated POSTs to /oauth2/token with request bodies containing fields outside the documented NrfAccessTokenAccessTokenReq schema.
Monitoring Recommendations
- Alert on sustained HTTP 500 rates from any single source IP targeting the NRF SBI.
- Capture full request bodies for /oauth2/token failures to support post-incident review of the form fields used.
- Track NRF process restarts and goroutine panic counters exported via metrics endpoints.
How to Mitigate CVE-2026-44325
Immediate Actions Required
- Upgrade free5GC to version 4.2.2 or later on all NRF deployments.
- Restrict network reachability of the NRF SBI to trusted 5G core peers using network policy or service mesh authorization.
- Enforce mutual TLS and OAuth2 client validation in front of the NRF to block unauthenticated callers.
Patch Information
The issue is fixed in free5GC 4.2.2. The upstream fix lands in the NRF repository through Pull Request #83 and commit f7bc77d. Operators should rebuild NRF images from the patched release and redeploy across all clusters. Additional background is documented in GitHub Issue #918.
Workarounds
- Place a Web Application Firewall or API gateway in front of /oauth2/token to reject requests whose form fields fall outside the expected NrfAccessTokenAccessTokenReq schema.
- Rate-limit unauthenticated requests to the NRF SBI to reduce the impact of repeated panic attempts.
- Isolate the NRF on a dedicated network segment that is not reachable from untrusted networks until the patched build is deployed.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
