Improper OAuth2 scope validation allows attackers to obtain high-privilege access tokens without authorization
Vulnerability Overview
CVE ID: CVE-2025-66719
Severity: Critical
CVSS v3.1 Score: 9.1 (Critical)
Exploitability: Remote network exploit, no authentication or privileges required, low complexity
Exploit Availability: Public exploit steps have been described in responsible disclosure discussions and can be reproduced with crafted access token requests
Affected Component: free5GC NRF (Network Repository Function) v1.4.0
Vulnerability Type: Logic flaw in OAuth2 access token scope validation (authorization bypass / privilege escalation)
Official patch / upgrade link: Link
What This Vulnerability Is
In 5G Core networks built on free5GC, the Network Repository Function (NRF) acts as a catalogue and coordination point between all 5G Network Functions (NFs). When one NF needs to communicate with another, it first requests an access token from the NRF. This token is supposed to allow only the specific actions (scopes) that the requesting NF is authorized to perform.
In free5GC NRF version 1.4.0, the code responsible for validating whether a requester is entitled to a particular scope contains a serious flaw. When a token request includes a specially crafted targetNF value, the scope validation logic is skipped entirely. As a result, the NRF issues an access token containing whatever scopes were requested, including scopes that should be restricted to highly privileged internal services.
In plain terms, powerful access tokens are issued to anyone who can reach the token endpoint with a slightly manipulated request. Once such a token is obtained, it can be used to access protected APIs across the 5G core that trust the token’s scope claims, enabling privilege escalation and unauthorized access to sensitive services.
Technical Root Cause
The vulnerability originates from improper logic in the access-token scope validation function within the NRF’s token generation code. When a crafted targetNF value is present in the request, the validation function exits early and does not enforce authorization checks on the requested OAuth2 scopes.
This allows the requester to fully control the scope values embedded in the issued token. Authentication of the request still occurs, but authorization of the scopes is not enforced, resulting in an authorization bypass.
What an Attacker Can Do
By exploiting this flaw, an attacker can:
- Request access tokens containing highly privileged scopes, including those used for subscriber data access (such as UDM or UDR services).
- Use these tokens to make authorized-looking API calls to other Network Functions that rely on scope-based access control.
- Access or modify sensitive subscriber data, authentication information, configuration stores, or service logic.
- Move laterally within the 5G core network and operate with the privileges of other Network Functions.
This is not limited to service disruption; it allows unauthorized access to sensitive data and core network functionality.
How Exploitation Works
In a legitimate flow, a Network Function contacts the NRF token endpoint to request an access token. The request normally contains:
- The NF identity
- The scopes being requested
- The target Network Function type
Due to the flawed logic, a crafted request containing a manipulated targetNF value and arbitrary scopes bypasses validation. The NRF returns an access token containing all requested scopes without verifying authorization. This token is then presented to downstream APIs that enforce access purely based on scope claims, resulting in unauthorized privileged operations.
Once such a token is obtained, it can be reused to access multiple protected Network Function APIs as if it were legitimate.
Proof-of-Concept Availability
Proof-of-concept demonstrations have been shown in responsible disclosure and project discussions. These demonstrate how to craft access-token requests that bypass scope validation and result in issuance of overly privileged tokens.
These PoCs are intended strictly for educational, testing, and defensive validation purposes and should only be executed in isolated laboratory environments. They must not be used in production systems.
Detection and Monitoring
If exploitation is attempted, abnormal patterns will be observable in authentication, authorization, and API usage logs.
Key Things to Log and Monitor
NRF Token Endpoint Activity
- Token request source and NF identity
targetNFortargetNfTypevalues- Requested OAuth2 scopes
- Token issuance success or failure
Issued Token Attributes
- Scope claims compared to expected NF permissions
- Tokens containing unusually broad or privileged scopes
Downstream Network Function Access
- API calls to UDM, UDR, or other sensitive services
- Token issuer and client identity versus requested operation
- Access patterns that differ from normal service behavior
Detection Rules You Can Apply
Suspicious Token Requests
- Token requests with unusual or manipulated
targetNFvalues - Requests for scopes outside the normal range for the requesting NF
- Tokens issued with scopes that do not align with the NF role
Scope Escalation Detection
- Tokens issued with scopes not normally associated with the NF type
- Tokens containing a significantly broader permission set than expected
API Access Mismatch
- Tokens used against APIs that the issuing NF does not normally access
- Privileged API calls originating from unexpected Network Functions
These detection concepts help identify abuse of valid-looking tokens for unauthorized actions.
Indicators of Exploitation
Indicators of potential exploitation include:
- Logs showing issuance of tokens with abnormal or excessive scopes
- API calls to UDM, UDR, or similar services from NFs that do not normally access them
- Network traffic showing unknown clients requesting highly privileged tokens
- Authorization errors caused by inconsistent or unexpected token claims
MITRE Classification
- CWE: CWE-863 — Incorrect Authorization
- MITRE ATT&CK Tactic: Privilege Escalation
- MITRE ATT&CK Technique: Abuse of Valid Accounts / Tokens
How This Affects Security Posture
Because this flaw allows access tokens to be issued with arbitrary privileges, it undermines nearly all scope-based access controls in the free5GC Service-Based Architecture. Any component that trusts those tokens becomes vulnerable once a malicious token is issued.
This can result in unauthorized data disclosure, unauthorized configuration changes, lateral movement between network services, and compromise of subscriber data integrity.
Mitigation and Remediation
The only reliable remediation is to apply the official fix or upgrade that corrects the scope validation logic.
Official patch / upgrade link:
https://github.com/free5gc/nrf/pull/73
Additional Hardening Measures
Until patching is completed, risk can be reduced by:
- Restricting network access to NRF token endpoints
- Allowing token requests only from explicitly trusted Network Functions
- Enforcing additional validation at API gateways or reverse proxies
- Increasing logging and alerting for token issuance and usage
These measures reduce exposure but do not eliminate the vulnerability.
Post-Patch Validation
After applying the fix, it should be confirmed that:
- Token requests with invalid or excessive scopes are rejected
- Scope validation is enforced for all
targetNFvalues - Logs do not show issuance of overly privileged tokens
- Previously issued tokens are reviewed and rotated if misuse is suspected
Final Takeaway
This is a critical authorization flaw that allows attackers to manipulate access-token generation in free5GC NRF and obtain tokens with arbitrary scopes. Those tokens can be used to access sensitive 5G core services and data. A patch is available at the link above, and detection relies on careful monitoring of token issuance, scope usage, and API access patterns.
