Skip to content

← Public intelligence

Go package

github.com/free5gc/pcf

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 6.5GoPublished

    free5GC's PCF npcf-policyauthorization POST /app-sessions panics on suppFeat=1 with missing AfRoutReq via nil pointer dereference

    CVE-2026-44317 · GHSA-wwqh-7jm5-gj7w

    Affected
    • Go github.com/free5gc/pcf < 1.4.3
    Fixed in
    1.4.3· Vendor fix available
    Issue
    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…

    Recommended action: Upgrade to 1.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. High, CVSS 7.5GoPublished

    free5GC's PCF npcf-smpolicycontrol POST /sm-policies panics on downstream UDR/OpenAPI 404 via nil pointer dereference

    CVE-2026-44316 · GHSA-wr8j-6chw-gm6p

    Affected
    • Go github.com/free5gc/pcf < 1.4.2
    Fixed in
    1.4.2· Vendor fix available
    Issue
    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 NpcfSMPolicyControl route group is mounted without inbound auth middleware (see free5gc/free5gc#844). So in the validation lab the trigger is fully…

    Recommended action: Upgrade to 1.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  3. High, CVSS 8.2GoPublished

    Free5GC PCF: Missing authentication middleware in Npcf_SMPolicyControl allows access to SM policy handlers and disclosure of subscriber SUPI

    CVE-2026-42083 · GHSA-6rgm-gr97-x3j5

    Affected
    • Go github.com/free5gc/pcf < 1.4.3
    Fixed in
    1.4.3· Vendor fix available
    Issue
    PCF NpcfSMPolicyControl missing authentication middleware allows unauthenticated access to SM policy handlers and disclosure of subscriber SUPI Details In NewServer(), the smPolicyGroup route group is created and routes are applied without attaching the router authorization middleware. In contrast, other PCF service groups such as NpcfPolicyAuthorization do attach RouterAuthorizationCheck before route registration. Because the middleware is missing, requests to the following endpoints can reach business logic even when no valid OAuth token is provided: - POST /npcf-smpolicycontrol/v1/sm-policies - GET /npcf-smpolicycontrol/v1/sm-policies/{smPolicyId} - POST /npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/update - POST /npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/delete This is visible at runtime because unauthenticated requests return business-level responses such as 400 or 404 instead of being rejected with 401 before handler execution. Under valid lab preconditions…

    Recommended action: Upgrade to 1.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  4. High, CVSS 7.5GoPublished

    free5GC PCF: Memory Leak via CORS Middleware Registration in HTTP Handler Leads to Denial of Service

    CVE-2026-41135 · GHSA-98cp-84m9-q3qp

    Affected
    • Go github.com/free5gc/pcf < 1.4.3
    Fixed in
    1.4.3· Vendor fix available
    Issue
    A memory leak vulnerability in the free5GC PCF (Policy Control Function) allows any unauthenticated attacker with network access to the PCF SBI interface to cause uncontrolled memory growth by sending repeated HTTP requests to the OAM endpoint. The root cause is a router.Use() call inside an HTTP handler that registers a new CORS middleware on every incoming request, permanently growing the Gin router's handler chain. This leads to progressive memory exhaustion and eventual Denial of Service of the PCF, preventing all UEs from obtaining AM and SM policies and blocking 5G session establishment. Details File: free5gc/pcf/internal/sbi/apioam.go Function: setCorsHeader(), called by HTTPOAMGetAmPolicy() The function setCorsHeader() invokes s.router.Use() on every incoming HTTP request: In the Gin framework, router.Use() appends a new HandlerFunc to the router's internal middleware slice. This operation is not idempotent — it does not replace existing middleware but appends a new…

    Recommended action: Upgrade to 1.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  5. Medium, CVSS 6.5GoPublished

    Free5GC is vulnerable to DoS through its Npcf_BDTPolicyControl POST API

    CVE-2025-60632 · GHSA-vgq7-9r5r-j9v3

    Affected
    • Go github.com/free5gc/pcf < 1.4.0
    Fixed in
    1.4.0· Vendor fix available
    Issue
    An issue was discovered in Free5GC v4.0.0 and v4.0.1 allowing an attacker to cause a denial of service via crafted POST request to the NpcfBDTPolicyControl API.

    Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →