free5GC NRF Accepts Unvalidated NF Profiles, Enabling Control-Plane Registration Poisoning

A newly published GitHub Security Advisory (GHSA-x8mj-6p3q-g5pp, CVE-2026-55068) reports that free5GC's Network Repository Function (NRF) does not validate NF Profile fields against the 3GPP TS 29.510 specification when handling registration requests to the nnrf-nfm service. According to the researcher, testing against the free5gc-fuzz:latest Docker image found that all 17 tested constraint violations — including malformed nfInstanceId values, out-of-enum nfStatus values, out-of-range heartBeatTimer values, null nfProfile fields, and unvalidated ipEndPoints — were accepted by the RegisterNFInstance handler with HTTP 200/201, with no configuration changes required.

The report states that because these forged profiles are stored and later returned via NFDiscover, any legitimate NF performing service discovery (AMF, SMF, AUSF, UDM, PCF, NSSF) could be directed to an attacker-supplied IP endpoint. The advisory describes an OAuth-enabled attack chain where a compromised NF with a valid token registers a fake AMF pointing at an attacker-controlled address, which is then selected by an SMF during routing. The researcher characterizes the potential impact as control-plane traffic interception, OAuth2 credential harvesting, and denial of service — and notes this differs from single-NF crash bugs in that a single poisoned profile can affect the entire 5G core service mesh. The advisory also notes that free5GC's default logging configuration (LogEnable: false) would leave no audit trail of such registrations.

This affects operators and researchers running free5GC-based 5G core deployments, particularly the referenced fuzz-testing Docker image; the advisory does not state whether the same code path is present in other free5GC deployment configurations or forks. No CVSS score has been assigned yet, and the item is tagged as PoC-public with the fix reported to maintainers but not confirmed as shipped.

Why It Matters

NRF is the trust anchor for service discovery in a 5G core — if profile registration isn't validated, any component with SBI (Service-Based Interface) network reachability can potentially inject itself into control-plane routing decisions for every other NF. For defenders running free5GC in lab, research, or production-adjacent contexts, this is a service-mesh-wide exposure rather than an isolated component bug, and the advisory's own PoC requires no authentication bypass beyond what SBI network access already provides.

What to Watch For / Do Now

• Confirm whether logging is enabled on your NRF instances (LogEnable in free5GC config) — the advisory notes the default is off, meaning registrations currently leave no trail to hunt through retroactively.
• If logging is enabled, monitor NRF PUT /nnrf-nfm/v1/nf-instances/{nfInstanceID} calls for anomalies: non-UUID nfInstanceId values, unexpected ipEndPoints IPs outside your known NF address ranges, or out-of-range heartBeatTimer values.
• Periodically diff the set of NF profiles returned by NFDiscover against an inventory of known-good NF instances and endpoints, looking for unexpected entries.
• Restrict SBI network access to only trusted NF components where possible, since the described attack path assumes network reachability to the NRF's registration endpoint.
• Track the upstream advisory for a patched release, since the report indicates a fix was proposed to maintainers but its shipped/merged status is not confirmed here.

Developing Intel

This is based on a single, same-day GitHub Security Advisory and reflects the researcher's testing methodology and claims as published; independent confirmation, a CVSS score, and vendor remediation status are not yet available. We will continue to track this. See the original advisory for full technical details: GHSA-x8mj-6p3q-g5pp.