CVE-2026-44327: free5GC NEF Authentication Bypass
Critical CVSS (10.0) reachable over network.
TL;DR - CVE-2026-44327 is a critical authentication-boundary flaw in free5GC NEF versions before 4.2.2. - Attackers who can reach the NEF Service-Based Interface (SBI) may access the
nnef-oamroute group without an authorization header. - Upgrade to free5GC 4.2.2 or later, restrict NEF access, and verify authorization on custom OAM routes. - The CVE is not currently listed in CISA KEV, and no confirmed in-the-wild exploitation was identified in the supplied data.
CVE-2026-44327 is a critical free5GC vulnerability affecting the Network Exposure Function (NEF) in versions before 4.2.2. The nnef-oam route group does not enforce inbound OAuth2 or bearer-token authorization at the route-group boundary, potentially allowing a reachable network attacker to receive a successful response without an Authorization header.
Organizations operating 5G core infrastructure should prioritize version discovery, SBI exposure review, and upgrade validation. For related 5G security context, see our VPN versus ZTNA comparison and forensic imaging glossary when investigating affected systems.
What Happened?
The vulnerability is located in the free5GC NEF’s nnef-oam route group. In affected releases, inbound OAuth2 or bearer-token authorization is not enforced before requests enter that group. A network attacker who can reach the NEF through the SBI may therefore request the route without presenting an authorization header.
The NVD record assigns CVE-2026-44327 a CVSS base score of 10.0, or Critical. The retrieved NVD response did not include the CVSS vector string, so defenders should verify the live NVD record before using individual metric values for automated prioritization.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-44327 |
| Product | free5GC Network Exposure Function (NEF) |
| Affected component | nnef-oam route group |
| Affected versions | free5GC versions before 4.2.2 |
| CVSS base score | 10.0 Critical |
| CVSS vector | Not supplied in the retrieved NVD response; verify directly in NVD |
| Attack vector | Network attacker able to reach the NEF SBI |
| Authentication required | No authorization header is required for the vulnerable route behavior |
| Fixed version | free5GC 4.2.2 |
| CISA KEV status | Not listed |
| Confirmed exploitation | No authoritative confirmation identified in the supplied NVD or CISA KEV data |
The immediate handler reportedly returns null, which may limit the direct functionality available through the currently implemented endpoint. That does not make the issue safe to ignore. The route-group authorization weakness could allow future OAM operations to inherit unauthenticated behavior unless each route independently implements protection.
Analyst’s take: Identify NEF instances running before 4.2.2 and determine whether their SBI is reachable from untrusted or broadly routed networks. The current handler may limit immediate data exposure, but it does not correct the route-group authorization failure or protect future OAM routes.
Root Cause
The root cause is missing inbound OAuth2 or bearer-token authorization middleware on the NEF’s nnef-oam route group. Authentication is not enforced before requests enter that group, allowing the application to return HTTP 200 OK to a request without an Authorization header.
This is both an authentication-boundary failure and a secure-defaults failure. Controls placed only on individual handlers are fragile because new handlers can be added without reproducing the required authorization logic. Enforcing authentication at the route-group boundary provides a safer default for current and future OAM operations.
The available research does not identify the exact upstream patch commit or provide a complete implementation diff. It does identify free5GC issue #861, the project’s GitHub security advisory, and NEF pull request #23 as relevant public references. Administrators should review those records when validating the precise middleware change in their source tree or downstream package.
The current OAM handler is described as a stub that returns null. That may reduce immediate data exposure, but it does not eliminate the security defect. An unauthenticated route can disclose implementation behavior, provide future attack surface, and create inconsistent security assumptions across a 5G core deployment.
Who Is Affected?
Organizations running free5GC with the NEF component should treat versions before 4.2.2 as affected. The supplied NVD record does not provide a more granular range, so the operational assumption should be that every earlier free5GC release requires assessment and remediation.
| Product or component | Affected range | Fixed version | Required action |
|---|---|---|---|
| free5GC NEF | Versions before 4.2.2 | 4.2.2 | Upgrade and validate OAM authorization |
NEF nnef-oam route group |
Present in affected NEF releases | 4.2.2 implementation | Test requests without and with valid authorization |
| Custom or downstream OAM routes | Deployment-specific | Not specified | Audit route-level and group-level middleware |
The issue is especially relevant when the NEF SBI is reachable from untrusted, partner, tenant, or broadly routed network segments. A network attacker still needs connectivity to the exposed NEF service, but network reachability should not be treated as an authorization control.
Teams that compile free5GC from source, use a downstream fork, or maintain custom NEF routes need additional review. Upgrading the upstream package may not automatically secure custom routes if they bypass the fixed route-group configuration or introduce separate handlers. Confirm the effective runtime configuration and inspect route registration in the deployed build.
CVSS Severity and Practical Risk
The NVD assigns CVE-2026-44327 a CVSS base score of 10.0, Critical. That severity is consistent with an authentication control failing on a network-reachable service: an attacker who can reach the affected NEF route does not need to present the expected bearer token or OAuth2 credential.
The retrieved NVD response did not include the complete CVSS vector string. Individual metric values for confidentiality, integrity, availability, scope, and user interaction should not be reconstructed or presented as authoritative here. Security teams should open the NVD record and confirm the published vector before importing metric-level values into risk-scoring systems.
The score should also be interpreted alongside deployment exposure. A private NEF SBI protected by segmentation, firewall policy, and service-to-service controls has a smaller reachable attack surface than an NEF exposed to an untrusted network. Those controls reduce practical exposure but do not remediate the underlying vulnerability or replace the upgrade.
Because the current handler is reportedly a stub, immediate impact may differ from that of a fully implemented OAM API. Nevertheless, CVSS evaluates the vulnerability and its potential consequences, not only current business functionality. The route-group design defect can expose future OAM functionality if the missing authentication boundary remains in place.
Exploitation Status
No confirmed in-the-wild exploitation was identified in the supplied NVD or CISA KEV information. CVE-2026-44327 is not currently listed in the CISA Known Exploited Vulnerabilities catalog, so there is no CISA-assigned remediation deadline or ransomware-campaign flag for this CVE.
No separate public exploit repository or standalone proof of concept was identified in the supplied research. Public technical references do exist, including the upstream issue, GitHub security advisory, and NEF pull request. These references document the vulnerability but should not be treated as evidence of active exploitation.
The absence of a known proof of concept or KEV listing is not evidence that exploitation is impossible. The behavior is straightforward to test against an authorized system: send a request to the relevant OAM route without an Authorization header and observe the response. Testing must be limited to systems owned or explicitly authorized by the operator.
Defenders should use a risk-based approach: prioritize internet-reachable or broadly reachable NEF instances, apply the fixed release, and review historical logs for unauthenticated requests. Continue monitoring CISA KEV, NVD updates, upstream advisories, and internal telemetry for changes in exploitation status.
Detection Guidance
Start by identifying every free5GC deployment that includes the NEF and recording its exact version. Package metadata, container tags, build manifests, and source revision records are preferable to relying on service banners. Any deployment running a version before 4.2.2 should be treated as exposed until upgraded or otherwise protected.
Next, review reverse-proxy, API-gateway, firewall, and NEF access logs for requests to the nnef-oam route group that lack a bearer token. A successful response is particularly important, but rejected requests can also indicate reconnaissance or attempted exploitation. Preserve timestamps, source addresses, HTTP methods, requested paths, status codes, and user-agent values.
A generic log search can be adapted to the actual logging schema:
# Illustrative pattern; confirm the exact OAM path and fields in your deployment
path contains "nnef-oam"
and (authorization is null or authorization == "")
and status >= 200
and status < 300
For JSON logs, a SIEM query might look like this:
service = "free5gc-nef"
AND url.path CONTAINS "nnef-oam"
AND NOT http.request.headers.authorization EXISTS
| STATS count(), values(source.ip), values(http.request.method)
BY url.path, http.response.status_code, bin(@timestamp, 15m)
The exact route path, field names, and logging behavior are deployment-specific. The research note does not provide a canonical URI, so defenders should not treat a guessed path as a complete network signature. Determine the actual registered OAM routes from the deployed NEF configuration or source, then tune the query.
A direct validation request should be performed only against an authorized test instance:
curl -i -X GET \
"https://<authorized-nef-host>:<port>/<verified-oam-path>"
Record whether the response is HTTP 200 without an Authorization header. Do not run this test against third-party infrastructure or production systems without an approved change and testing plan. After remediation, repeat the test and confirm that an unauthenticated request is denied while an appropriately authorized request follows the expected authentication path.
Remediation and Patching
Upgrade free5GC to version 4.2.2 or later. The precise installation command depends on whether the deployment uses a source checkout, container image, distribution package, or internal build pipeline. Do not assume that changing a configuration value updates the NEF code; verify that the running binary or image actually contains the fixed release.
For a source-based deployment, a generic upgrade workflow is:
git fetch --tags origin
git checkout v4.2.2
# Rebuild using the project's documented build procedure
make
# Restart the NEF using the deployment's approved service mechanism
sudo systemctl restart free5gc-nef
The tag and build commands must be checked against the project’s packaging and deployment instructions. If the installation is containerized, update the image reference to an image built from free5GC 4.2.2 or later, redeploy through the normal orchestration workflow, and verify the running version from container metadata or the build manifest.
After upgrading, validate all of the following:
- The NEF reports or can be correlated to free5GC 4.2.2 or later.
- The
nnef-oamroute group enforces OAuth2 or bearer-token authorization. - A request without an
Authorizationheader no longer receives the vulnerable successful response. - Valid service-to-service credentials continue to work.
- Custom and downstream OAM routes do not bypass the fixed middleware.
- Logs do not show unexpected unauthenticated successful access after the change.
Until the upgrade is complete, restrict the NEF SBI to trusted service networks. Use firewall rules, security groups, routing controls, and, where appropriate, an authenticated API gateway or reverse proxy. This is a compensating control, not a replacement for patching.
The upstream material supplied does not define a supported configuration-only workaround that fixes the missing route-group middleware inside the application. If an emergency code-level mitigation is required, apply the project’s upstream authorization change from the referenced advisory or pull request only after reviewing and testing it, then integrate it into the organization’s source-control and build process. Avoid ad hoc edits to production binaries.
Organizations with custom routes should explicitly attach the required authorization middleware to those routes and confirm effective route registration at runtime.
Incident Response Considerations
If logs show unauthenticated requests to the affected OAM route, preserve the relevant records before rotating or deleting them. Capture:
- Source IP addresses and network segments
- Request timestamps and time zones
- HTTP methods and paths
- Response status codes and response sizes
- User-agent and forwarded-header values
- Reverse-proxy, gateway, and NEF logs
- Running free5GC version and deployed image or source revision
Determine whether the requests were limited to reconnaissance or reached implemented OAM functionality. Review changes to NEF configuration, route registration, credentials, and adjacent 5G core services. If compromise cannot be ruled out, follow the organization’s incident-response process and consider rotating credentials or tokens associated with affected service-to-service communications.
References
The primary authoritative record is the NVD entry for CVE-2026-44327. It provides the affected project, component, version boundary, severity information, and fixed version. Because the retrieved response did not include the vector string, consult the live record before relying on CVSS metric details.
Upstream references include free5GC issue #861, the free5GC GitHub security advisory GHSA-cmpj-2x3g-m7g3, and free5GC NEF pull request #23. Review these sources for the exact implementation change and deployment-specific guidance.
For exploitation status, consult the CISA Known Exploited Vulnerabilities Catalog. As of the information available for this article, CVE-2026-44327 is not listed there. Its absence means no CISA KEV confirmation or deadline applies; it does not remove the need to patch reachable or business-critical NEF deployments.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.