CVE-2026-44327
Received Received - Intake
NEF OAM Route Group Missing Authorization in free5GC

Publication date: 2026-05-27

Last updated on: 2026-05-27

Assigner: GitHub, Inc.

Description
free5GC is an open-source implementation of the 5G core network. Prior to 4.2.2, 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. This vulnerability is fixed in 4.2.2.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-27
Last Modified
2026-05-27
Generated
2026-05-28
AI Q&A
2026-05-27
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
free5gc free5gc to 4.2.2 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-862 The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
CWE-306 The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability in free5GC's NEF component allows unauthenticated access to administrative OAM routes, which can lead to unauthorized access and potential manipulation of network functions. This structural lack of authentication on critical administrative interfaces can compromise confidentiality, integrity, and availability of the system.

Such unauthorized access risks violating common security requirements found in standards and regulations like GDPR and HIPAA, which mandate strict access controls and protection of sensitive data to ensure privacy and security.

Therefore, this vulnerability could negatively impact compliance with these regulations by exposing the system to unauthorized access and potential data breaches.


Can you explain this vulnerability to me?

This vulnerability exists in free5GC, an open-source 5G core network implementation, specifically in versions prior to 4.2.2. The NEF component mounts the nnef-oam route group without requiring inbound OAuth2 or bearer-token authorization. This means a network attacker who can access the NEF on the SBI interface can send requests to the OAM route without any Authorization header and still receive a 200 OK response. Although the current OAM handler is a stub that returns null, the underlying issue is that the entire OAM route group lacks inbound authentication middleware. Consequently, any future operations added to this route group will inherit this missing authentication boundary by default.


How can this vulnerability impact me? :

This vulnerability can have severe impacts because it allows unauthenticated network attackers to access the OAM route group on the NEF component without any authorization checks. Given the CVSS score of 10.0 with high impact on confidentiality, integrity, and availability, an attacker could potentially execute unauthorized operations, manipulate data, or disrupt services within the 5G core network. Since the OAM route group currently lacks any authentication, future operations added to this group will also be vulnerable, increasing the risk of exploitation.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, upgrade free5GC to version 4.2.2 or later, where the missing inbound OAuth2/bearer-token authorization on the NEF's OAM route group is fixed.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by sending an unauthenticated HTTP GET request to the NEF's OAM route and checking if it returns a 200 OK response without requiring an Authorization header.

A simple command to test this is using curl:

  • curl -i http://<NEF_IP>:<NEF_PORT>/nnef-oam/v1/ -H "Authorization:"

If the response status is 200 OK despite the missing Authorization header, the system is vulnerable. This indicates that the OAM route group is mounted without inbound OAuth2 or bearer-token authorization.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart