free5GC Hit by Five Critical Auth Bypass Flaws: CVE-2026-44315/26/27/29/30

On May 27, 2026, free5GC, the open-source 5G mobile network implementation used in university and carrier research labs around the world, was hit with the simultaneous disclosure of five critical authentication bypass vulnerabilities. Three of them carry the maximum CVSS score of 10.0. All affect versions up to and including v4.2.1, and all are fixed in v4.2.2.

The trouble sits in two core components of the 5G control plane: the NEF (Network Exposure Function) and the SMF (Session Management Function). API endpoints that are supposed to require an OAuth2 bearer token were instead returning 200 OK to requests with no authorization header at all, thanks to a middleware configuration gap.

All five CVEs were reported to the free5GC team by Taiwan-based researcher LinZiyuu, and the project published them as five concurrent GHSA advisories on its GitHub repository on May 27, 2026.

What free5GC Is

free5GC is an open-source project, led by Taiwan's National Yang Ming Chiao Tung University (NYCU), that implements the full 5G mobile network "core" in code anyone can read and run. A mobile network is made up of base stations (the radio antenna side) and a back-end control system called the core network, which handles user authentication, session management, billing, and quality-of-service. free5GC reproduces that core entirely as OSS.

Typical deployments include:

• University and graduate-school telecom labs using it as a teaching platform for 5G experiments
• Network equipment vendors and startups using it in place of expensive commercial simulators when testing their own products
• Carrier R&D; divisions running it as a PoC environment for new features
• Academic papers reaching for it as an evaluation testbed, alongside Magma and OpenAirInterface as a representative OSS 5G core
• Small-scale commercial use as the foundation of private 5G pilots in factories, warehouses, and campus networks

The implementation hews closely to the 3GPP (3rd Generation Partnership Project) standards, which means it speaks the same protocols and APIs as a real commercial 5G core. That makes it excellent for teaching and testing, but it also means it shares the same attack surface as a production network. The vulnerabilities disclosed this week target exactly that attack surface: the Service-Based Interface (SBI) APIs defined by 3GPP.

In Japan as well, free5GC is far from unusual in university telecom research labs, 5G-focused startups, and carrier research institutes. Some private 5G pilots have adopted it for their core, so the blast radius is not limited to "research-only OSS."

The Common Root Cause: Missing Authorization Middleware

Structurally, all five CVEs are the same defect. The OAuth2 bearer-token authorization mandated by the 3GPP standards was simply not applied as middleware when certain route groups were attached to the HTTP server.

In a 5G core, every inter-component call (NEF calling SMF, SMF calling PCF, and so on) is supposed to be gated by an OAuth2 bearer token issued by the NRF (Network Repository Function). free5GC's codebase wires up authorization middleware at the route-group level rather than per individual endpoint, but several of those groups had no middleware attached at all. As a result, every endpoint under those groups happily responded without any authorization header.

The fact that the same pattern repeats in five places suggests the oversight was structural rather than a one-off. Even when a service is "disabled" in the configuration file, the route mount itself still runs, so the attack surface is not actually closed. That breaks the common defensive assumption that "if it's disabled in config, it's safe."

The Five CVEs In Detail

CVE-2026-44327: NEF OAM Route Authentication Bypass (CVSS 10.0)

NEF's operations and management endpoints (under /nnef-oam/v1/) return 200 OK to a GET request with no authorization header. The NVD classification combines CWE-306 (missing authentication for a critical function) and CWE-862 (missing authorization). The GHSA advisory documents that the NEF service logs "OAuth2 configuration received from NRF: true" while in practice not validating the authorization header at all. The current OAM handler is a stub, but the structural problem is that any future operations features added under this route would be exposed without authentication. The validation target was a NEF container running v4.2.0 (commit 5ce35eab).

CVE-2026-44329: SMF UPI Management Route Authentication Bypass (CVSS 10.0)

The SMF's UPI (User Plane Interface) management route group was mounted without OAuth2/bearer-token authorization middleware. The GHSA advisory demonstrates the flaw by contrast: OAM routes on the same SMF instance return 401 Unauthorized, while the UPI routes return 200 OK. An attacker could perform the following operations anonymously:

• GET /upi/v1/upNodesLinks: anonymously retrieve topology information for user-plane nodes and links
• POST /upi/v1/upNodesLinks: inject a fake UPF node entry with attacker-controlled parameters
• DELETE /upi/v1/upNodesLinks/{nodeID}: delete a topology entry

If exploited, an attacker can inject a rogue UPF (User Plane Function) entry into the core network. This is "topology poisoning": subsequent UPF selection logic can be steered toward an attacker-controlled node, opening a path to disrupt PDU session establishment across an entire network slice.

CVE-2026-44330: NEF nnef-pfdmanagement Route Authentication Bypass (CVSS 10.0)

The NEF's nnef-pfdmanagement route group (GHSA advisory) was mounted without authorization middleware. The code location is NFs/nef/internal/sbi/server.go:56. The NVD classification is CWE-863 (incorrect authorization). The attack enables:

• Confidentiality: anonymously read PFD (Packet Flow Description) data registered by an AF (Application Function), exposing traffic-classification policies including URL regexes and application identifiers
• Integrity: create change-notification subscriptions pointing at attacker-controlled destinations, abusing the NEF as a launchpad for anonymous outbound requests
• Availability: delete legitimate subscriptions to cut off PFD update notifications

CVE-2026-44315: NEF 3gpp-pfd-management Route Authentication Bypass (CVSS 9.4)

The NEF's 3GPP-standard PFD management API route (GHSA advisory) was mounted without OAuth2/bearer-token authorization. An attacker could create, read, or delete PFD management transaction state using a forged bearer token or any arbitrary bearer header. Disabling the service in configuration does not close this route off, which is the reason for the CVSS 9.4 weighting.

CVE-2026-44326: NEF 3gpp-traffic-influence Route Authentication Bypass (CVSS 9.4)

The NEF's traffic-influence API route (GHSA advisory) was mounted without OAuth2/bearer-token authorization. An attacker could manipulate traffic-influence subscriptions using a forged token or with no authorization header at all. Because it lets an attacker rewrite the traffic-steering decisions for a specific group or arbitrary UE to a path of their choosing, it twists the foundation of QoS guarantees across a 5G network slice.

Attack Scenarios: Beyond The Research Lab

free5GC often gets filed under "research OSS," but there are several scenarios in which these vulnerabilities translate into real-world damage.

First, private 5G pilots. Private 5G trials in factories, warehouses, and campus networks have been growing in Japan as well, and some pick free5GC for the core. If the SBI (Service-Based Interface) is reachable from outside that intended network, an attacker can inject or delete UPF entries anonymously, taking down communications across an entire factory line.

Second, university and research-institute testbeds. Multiple free5GC environments often live on the same network, run by different students or researchers. If one lab's test environment is compromised and the SBI of other labs on the same LAN is reachable, the attacker can pivot laterally and poison the topology across multiple environments. The integrity of research data and experimental results takes a direct hit.

Third, PoC environments backing academic papers. Many research groups use free5GC as the evaluation environment for their published work. It is impossible to rule out that benchmark numbers gathered on a vulnerable version were influenced by attacker-driven topology manipulation. Papers that explicitly state results obtained on "free5GC v4.2.1 or earlier" may be candidates for re-evaluation.

Fourth, while commercial 5G cores (products from Ericsson, Nokia, Huawei, Mavenir, and others) are not directly implicated, free5GC's implementation tracks 3GPP closely. That makes this disclosure a reminder to revisit whether the same kind of missing authorization middleware might also lurk in other commercial implementations. LinZiyuu's report is a wake-up call beyond just free5GC.

What To Do Now

1. Upgrade free5GC to v4.2.2 or later. Grab v4.2.2 from the official releases page. If you are running it via Docker Compose, the fastest path is to switch each NF (NEF, SMF, and the rest) container image to the latest tag. Confirm that the fix commit e23ce97565f285eb99eed153743c62bf4c767c6e and the related pull requests (nef PR#23, smf PR#197) are merged into your build.

2. Restrict network reachability of the SBI. Until you have applied the fixed version, make sure the NEF and SMF SBI endpoints are not directly reachable from outside networks or from a flat campus-wide LAN. Use Kubernetes NetworkPolicy, Docker internal networks, or firewall rules to constrain access to other NFs inside the core network only.

3. Audit logs going back at least a month. Look for access to /upi/v1/, /3gpp-pfd-management/, /3gpp-traffic-influence/, /nnef-pfdmanagement/, and /nnef-oam/ with no authorization header or an unusual bearer token. Any case where the access log shows an HTTP 200 response is a strong signal of successful exploitation.

4. Cross-check actual UPF topology, PFD policies, and traffic-influence subscriptions on the running system. Verify that the node list, policies, and subscriptions actually registered in free5GC match what is supposed to be there per configuration. Any diff should be treated as a potential attacker injection.

5. Re-examine paper and report reproducibility. For experimental results collected over the past six months on free5GC v4.2.1 or earlier, you cannot fully rule out attacker-driven topology poisoning. The conservative call is to re-run experiments on v4.2.2. If the paper is already published, consider adding a reproducibility note.

CISA KEV Status And Related Coverage

As of May 28, 2026, CVE-2026-44315/44326/44327/44329/44330 are not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. Because free5GC is research-, education-, and PoC-oriented OSS rather than a commercial 5G core, it falls outside KEV's "products that ought to be in U.S. federal agency production environments" scope. That said, as private 5G and industrial IoT infrastructure deployments grow, structural defects like these have every chance of being folded into real attack playbooks.

We keep a running list of CVEs that CISA has confirmed as actively exploited, along with their remediation deadlines, in the CISA KEV Dashboard (Japanese). free5GC entries are not in scope right now, but it is worth tracking them alongside the previously listed 5G-adjacent commercial gear (Ericsson, Cisco, and Citrix-family telecom equipment).

free5GC is built from Go modules and pulls in a substantial number of Go libraries through its OSS dependency graph. The OSS Supply Chain Scanner lets you see the latest CVE status for free5GC and its Go dependencies in one place.

References

• ▸ NVD - CVE-2026-44315 (NEF 3gpp-pfd-management)
• ▸ NVD - CVE-2026-44326 (NEF 3gpp-traffic-influence)
• ▸ NVD - CVE-2026-44327 (NEF OAM)
• ▸ NVD - CVE-2026-44329 (SMF UPI management)
• ▸ NVD - CVE-2026-44330 (NEF nnef-pfdmanagement)
• ▸ GHSA-cmpj-2x3g-m7g3 (CVE-2026-44327)
• ▸ GHSA-3258-qmv8-frp3 (CVE-2026-44329)
• ▸ GHSA-rwww-x45w-p52w (CVE-2026-44330)
• ▸ GHSA-5f62-53r8-qrqf (CVE-2026-44315)
• ▸ GHSA-3p28-73q7-45xp (CVE-2026-44326)
• ▸ free5GC official site
• ▸ free5GC release history