CVE-2026-59358: UAA OAuth Token Endpoint Vulnerability allows user access token reuse for client_credentials grant type
Improper authentication (CWE-287) in the OAuth token endpoint in Cloud Foundry UAA allows a remote, authenticated attacker holding a valid user access token to obtain a fully-privileged clientcredentials token for the OAuth client that issued it, by presenting the user token as an OAuth 2.0 Bearer credential on a clientcredentials grant request in place of the client’s configured secret.
UAA’s clientcredentials handling does not verify that the Bearer credential supplied for client authentication is actually a client credential (a client secret or a valid configured client authentication method); it accepts any valid access token whose clientid matches the request. A token obtained by a normal end user through a public authorizationcode + PKCE flow — scoped only to uaa.user, carrying a userid, and recording clientauthmethod=none — satisfies this check. That user token cannot itself administer OAuth clients (POST /oauth/clients correctly returns 403), but when replayed as Bearer authentication on a clientcredentials request for the same client, UAA issues a new client-only token carrying the client’s full authorities, such as clients.write. An attacker can use that token to create arbitrary new OAuth clients, including clients with attacker-chosen authorities, without ever possessing the client’s actual secret.
Exploitation requires a valid user access token (the attacker’s own) for a client that is configured to support both a public, user-facing authorization flow and the clientcredentials grant type on the same clientid — a non-default combination. Practical impact scales with the authorities assigned to that client.
Affected Software
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
The attacker needs a valid user access token issued for the same OAuth client targeted in the client_credentials request. A token obtained through a public authorization_code + PKCE flow, even if scoped only to uaa.user and using client_auth_method=none, can satisfy this requirement.
What access can the attacker gain after exploiting it?
UAA can issue a client-only token with the targeted OAuth client's full authorities. For example, this may include clients.write even though the original user token cannot directly administer OAuth clients.