CVE-2026-44317
Received Received - Intake
PCF Panic on Missing RouteReq in free5GC

Publication date: 2026-05-27

Last updated on: 2026-05-27

Assigner: GitHub, Inc.

Description
free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC's PCF POST /npcf-policyauthorization/v1/app-sessions handler panics on a single authenticated request whose ascReqData.suppFeat == "1" (enabling traffic-routing feature negotiation) and whose medComponents entries supply an afAppId but NO AfRoutReq. The create path then calls provisioningOfTrafficRoutingInfo(smPolicy, appID, routeReq, ...) with routeReq == nil and dereferences routeReq.RouteToLocs (and other fields) without a nil check, causing runtime error: invalid memory address or nil pointer dereference. Gin recovery converts the panic into HTTP 500. This vulnerability is fixed in 4.2.2.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-27
Last Modified
2026-05-27
Generated
2026-05-28
AI Q&A
2026-05-27
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
free5gc free5gc to 4.2.2 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
CWE-754 The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by sending an authenticated POST request to the /npcf-policyauthorization/v1/app-sessions endpoint of the free5GC PCF component with the ascReqData.suppFeat field set to "1" and medComponents entries including an afAppId but no AfRoutReq. Such a request triggers a panic resulting in an HTTP 500 Internal Server Error response.

A practical detection method is to craft and send this specific request using a tool like curl or any HTTP client that supports OAuth2 authentication tokens.

  • Use curl to send a POST request with a valid OAuth2 token and the crafted JSON payload that sets suppFeat to "1" and includes medComponents with afAppId but omits AfRoutReq.
  • Observe if the server responds with HTTP 500 errors, indicating the vulnerability is present.

Example curl command (replace <TOKEN> and <PCF_URL> accordingly):

  • curl -X POST <PCF_URL>/npcf-policyauthorization/v1/app-sessions -H "Authorization: Bearer <TOKEN>" -H "Content-Type: application/json" -d '{"ascReqData": {"suppFeat": "1"}, "medComponents": [{"afAppId": "someAppId"}]}' -v

If the server crashes or returns HTTP 500 errors upon this request, it indicates the presence of the vulnerability.


Can you explain this vulnerability to me?

This vulnerability exists in free5GC, an open-source 5G core network implementation, prior to version 4.2.2. It occurs in the PCF POST /npcf-policyauthorization/v1/app-sessions handler when it receives a single authenticated request with specific conditions: the ascReqData.suppFeat field equals "1" (which enables traffic-routing feature negotiation), and the medComponents entries include an afAppId but do not include an AfRoutReq.

Under these conditions, the code calls the function provisioningOfTrafficRoutingInfo with a nil routeReq parameter. The function then attempts to access fields of routeReq without checking if it is nil, leading to a runtime error caused by dereferencing a nil pointer. This causes the application to panic, which the Gin framework recovers from by returning an HTTP 500 error.

This vulnerability is fixed in free5GC version 4.2.2.


How can this vulnerability impact me? :

This vulnerability can cause the free5GC PCF component to panic and return HTTP 500 errors when processing certain authenticated requests. This results in a denial of service condition where legitimate traffic-routing requests may fail, potentially disrupting network operations.

Since the vulnerability leads to a runtime error and service interruption, it can impact the availability of the 5G core network functions relying on free5GC, affecting users and services dependent on those network capabilities.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, upgrade free5GC to version 4.2.2 or later, where the issue has been fixed.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart