https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 23:36:17 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-322465 EUVD-2026-322465 https://cve.radiocsirt.org/vuln/euvd-2026-322465 https://cve.radiocsirt.org/vuln/fkie_cve-2026-44329 <p>free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC&#39;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. This vulnerability is fixed in 4.2.2.</p> <p>free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, free5GC&#39;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. This vulnerability is fixed in 4.2.2.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-44329 https://cve.radiocsirt.org/vuln/ghsa-3258-qmv8-frp3 <p><strong>Affected:</strong> Go: github.com/free5gc/smf</p> <p>### Summary free5GC&#39;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.</p> <p>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.</p> <p>### 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</p> <p>Control comparison on the same SMF instance: - `GET /upi/v1/upNodesLinks` (no token) -&gt; `200 OK` - `GET /nsmf-oam/v1/` (no token) -&gt; `401 Unauthorized`</p> <p>This side-by-side proves OAuth2 middleware is wired in for `nsmf-oam` but not for `UPI` on the same process.</p> <p>Code evidence (paths in `free5gc/smf`): - UPI group mounted WITHOUT auth middleware: `NFs/smf/internal/sbi/server.go:…</p> <p><strong>Affected:</strong> Go: github.com/free5gc/smf</p> <p>### Summary free5GC&#39;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.</p> <p>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.</p> <p>### 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</p> <p>Control comparison on the same SMF instance: - `GET /upi/v1/upNodesLinks` (no token) -&gt; `200 OK` - `GET /nsmf-oam/v1/` (no token) -&gt; `401 Unauthorized`</p> <p>This side-by-side proves OAuth2 middleware is wired in for `nsmf-oam` but not for `UPI` on the same process.</p> <p>Code evidence (paths in `free5gc/smf`): - UPI group mounted WITHOUT auth middleware: `NFs/smf/internal/sbi/server.go:…</p> https://cve.radiocsirt.org/vuln/ghsa-3258-qmv8-frp3