Description

An attacker that holds an OAuth2 token granting only part of the required scopes can authenticate, because when more than one scope is required in the configuration, the remote token validation paths accept a token that carries only one of them, while the local token validation path correctly requires all of them. The configured authorization policy is not enforced, so a token that was granted only part of the required permissions is accepted where it should have been rejected. Use local token validation where tokens can be validated locally. Update to non-vulnerable version. No publicly available exploits are known.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-28T12:16:29.140Z",
  "pubdate": "2026-08-28T12:16:29.140Z",
  "executiveSummary": "This vulnerability involves an authorization bypass in OAuth2 token validation mechanisms where remote validation endpoints fail to enforce mandatory scope conjunctions. While local validation paths correctly verify that all required scopes are present within an OAuth2 token, the remote validation path erroneously accepts tokens containing only a subset of the required permissions. This discrepancy allows an attacker in possession of a limited-scope token to bypass authorization policies and gain unauthorized access to protected resources that should have been restricted.\nThe flaw impacts systems configured to use remote token validation for OAuth2. The primary risk implication is an escalation of privilege, as attackers can perform actions or access data for which they have not been explicitly authorized. Exploitation requires the attacker to hold a valid OAuth2 token that possesses at least one of the required scopes, allowing them to circumvent more stringent authorization requirements. No specialized public exploits are currently documented, but the nature of the flaw permits unauthorized interaction with protected endpoints, undermining the principle of least privilege.",
  "technicalDetails": "The root cause of this vulnerability lies in an inconsistent implementation of OAuth2 scope validation logic across different validation pathways. Specifically, the system utilizes two distinct methods for validating incoming tokens: a local validation path and a remote validation path. The local validation path correctly interprets the security configuration by performing an intersection check, ensuring that the token carries every scope mandated by the defined authorization policy.\nConversely, the remote token validation path exhibits a logic flaw where it interprets multiple required scopes as an 'OR' condition rather than an 'AND' condition. When an authorization policy is configured to require multiple specific scopes, the remote validation logic grants access if the token contains any one of the required scopes, effectively bypassing the intended security constraints.\nThe attack flow proceeds as follows: 1) An attacker obtains a legitimate OAuth2 token from an authorization server. This token is scoped narrowly, containing only a subset of the total permissions required by the target resource. 2) The attacker submits this token to the protected resource. 3) The resource service delegates the validation to the remote validation endpoint. 4) The remote validator erroneously returns a positive validation response because the provided token satisfies at least one of the multiple required scopes. 5) The service grants the attacker access to the requested functionality or data, despite the attacker lacking the full suite of required permissions.\nThis vulnerability is particularly significant in environments where remote validation is used for distributed architecture or load-balanced services. Since the local validation path is not affected, the system exhibits heterogeneous security posture depending on the internal routing of the request. The impact is a breach of the authorization model, allowing authenticated users to traverse boundaries and access protected endpoints that require higher privilege levels than those granted by their existing token scopes.\nThere are no specific public exploits or specialized payloads required for this vulnerability, as it is a logical flaw in the backend validation routine. The vulnerability manifests upon legitimate submission of a partially scoped token to an endpoint utilizing the remote validation mechanism. The post-exploitation impact includes unauthorized data access, potential data manipulation, and the ability to execute operations within the context of the service that should have been restricted by the intended scope conjunction policy."
}