EUVD-2026-32571
GHSA-cmpj-2x3g-m7g3
Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H
Pre-auth network reach with no complexity gives AV:N/AC:L/PR:N/UI:N, but the live OAM handler is a stub returning null, so only low confidentiality (enumeration) applies today - hence I diverge from the vendor's forward-looking 10.0.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
3DescriptionGitHub Advisory
Summary
free5GC's NEF mounts the nnef-oam route group without inbound OAuth2/bearer-token authorization. A network attacker who can reach NEF on the SBI can hit the OAM route with no Authorization header at all and the handler returns 200 OK. The current OAM handler is a stub that returns null, but the structural defect is route-group-scoped: the entire OAM route group has no inbound auth middleware, so every future OAM operation added to this group inherits the missing auth boundary by default. Same root cause as the NEF traffic-influence and PFD-management findings.
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.0 - Runtime NEF commit:
5ce35eab - Docker validation date: 2026-03-11
NEF advertises OAuth2 setting receive from NRF: true, yet the OAM route group is mounted without any inbound auth middleware and answers unauthenticated GETs with 200 OK.
Code evidence (paths in free5gc/nef):
- OAM route group mounted without auth middleware:
NFs/nef/internal/sbi/server.go:60 - OAM route exposed at
/:NFs/nef/internal/sbi/api_oam.go:9 - OAM processor returns
200 OKdirectly:NFs/nef/internal/sbi/processor/oam.go:9 - NEF context only exposes outbound token acquisition (
GetTokenCtx); there is no inbound authorization path:NFs/nef/internal/context/nef_context.go:153
PoC
Reproduced against the running NEF at http://10.100.200.19:8000 with no Authorization header:
curl -i http://10.100.200.19:8000/nnef-oam/v1/Observed output:
HTTP/1.1 200 OK
nullNEF container logs (docker logs nef) show the request being served while OAuth is enabled:
[INFO][NEF][GIN] | 200 | GET | /nnef-oam/v1/Impact
Missing inbound authentication (CWE-306) and authorization (CWE-862) on the NEF OAM SBI route group. Severity is scored against the OAM route group's intended capability surface (Operations / Administration / Maintenance), NOT against the current stub handler. The current handler is a stub that returns null, but the defect is route-group-scoped: there is no auth middleware on the group at all, so every future OAM operation added behind this group inherits the missing inbound auth boundary by default.
Any party that can reach NEF on the SBI can:
- Probe and enumerate the OAM route surface anonymously today.
- Hit any future OAM-group endpoint (read, modify, restart-style operations) anonymously, because the auth boundary does not exist for this group.
Operators who assume OAuth2 setting receive from NRF: true enforces inbound auth on NEF are wrong for this route group.
Affected: free5gc v4.2.1.
Upstream issue: https://github.com/free5gc/free5gc/issues/861 Upstream fix: https://github.com/free5gc/nef/pull/23
AnalysisAI
Authentication bypass in free5GC's NEF (Network Exposure Function) lets any host that can reach the Service-Based Interface (SBI) call the nnef-oam route group with no Authorization header and receive HTTP 200, despite the NEF advertising 'OAuth2 setting receive from NRF: true'. The defect is route-group-scoped (CWE-306): the OAM group is mounted with no inbound auth middleware, so the current stub (which returns null) and any future OAM read/modify/restart operation added to the group inherit an open, unauthenticated boundary. A working PoC (a single unauthenticated curl) is published in the GHSA advisory; EPSS is very low (0.04%) and it is not in CISA KEV.
Technical ContextAI
free5GC is an open-source implementation of a 3GPP 5G Core. The NEF exposes northbound/OAM APIs over the SBI, a REST/HTTP2 interface where 5G Network Functions authenticate each other with NRF-issued OAuth2 bearer tokens. In 5G SBI security, each service consumer is supposed to present a bearer token scoped to the target service name, and the producer must verify it inbound. Here the root cause is CWE-306 (Missing Authentication for a Critical Function): per the code evidence, the OAM route group is registered in NFs/nef/internal/sbi/server.go:60 without any auth middleware, the OAM route is exposed at api_oam.go:9, and the processor (processor/oam.go:9) returns 200 directly. The NEF context (nef_context.go:153) only implements outbound token acquisition (GetTokenCtx) and had no inbound authorization path, so OAuth2 was enforced only when NEF acts as a client, never as a server for the OAM group. The advisory also flags CWE-862 (Missing Authorization). Affected package per CPE is pkg:go/github.com/free5gc/nef.
RemediationAI
Upgrade free5GC to 4.2.2 or later, which per ENISA EUVD-2026-32571 is the fixed release; the upstream fix is free5gc/nef PR #23 (https://github.com/free5gc/nef/pull/23), which introduces an NFContext.AuthorizationCheck method invoking oauth.VerifyOAuth on the inbound bearer token per service name and wires callback/traffic-influence services accordingly - because this landed as a pull request, operators should confirm their built image actually contains the merged commit rather than assuming a tagged release. Until upgraded, do not expose NEF's SBI beyond the trusted 5G core network segment: restrict network reachability to the SBI port (validation used http://10.100.200.19:8000) so only legitimate NF peers and the NRF can reach it, and specifically block external/AF-adjacent access to the /nnef-oam/v1/ path at a reverse proxy or service mesh, verifying the OAuth2 bearer token there. Trade-off: proxy-level token enforcement duplicates logic the fix adds natively and can break legitimate NF-to-NEF calls if scopes are misconfigured, so validate against known-good NF traffic before enforcing. Advisory and patch references: https://github.com/free5gc/free5gc/security/advisories/GHSA-cmpj-2x3g-m7g3 and https://github.com/free5gc/nef/pull/23.
An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl
runc through version 1.0-rc6 (used in Docker before 18.09.2) contains a container escape vulnerability that allows attac
Netmaker makes networks with WireGuard. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no a
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
The News & Blog Designer Pack - WordPress Blog Plugin - (Blog Post Grid, Blog Post Slider, Blog Post Carousel, Blog Post
Path traversal in JFrog Artifactory (CWE-22) enables an authenticated low-privilege user to write data outside the inten
Docker 1.3.2 allows remote attackers to execute arbitrary code with root privileges via a crafted (1) image or (2) build
Remote code execution in Gogs through 0.14.2 allows authenticated users (and unauthenticated attackers on default-config
Remote code execution in Flowise before 3.1.2 allows any authenticated user (or API caller with chatflow view/update per
Remote code execution in NocoBase Workflow Script Node (npm @nocobase/plugin-workflow-javascript) allows authenticated l
Docker Desktop Community Edition before 2.1.0.1 allows local users to gain privileges by placing a Trojan horse docker-c
Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 25.2.169 and Application prior to version 2
Same technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today