UAA’s client_credentials 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 client_id matches the request. A token obtained by a normal end user through a public authorization_code + PKCE flow — scoped only to uaa.user, carrying a user_id, and recording client_auth_method=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 client_credentials 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 client_credentials grant type on the same client_id — a non-default combination. Practical impact scales with the authorities assigned to that client.
Metrics
Affected Vendors & Products
No data.
No data.
No data.
OpenCVE Enrichment is a feature of OpenCVE that uses AI to automatically link vendors and products to CVEs. Learn more on GitHub.
No data.
No advisories yet.
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Tue, 06 Oct 2026 15:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Tue, 06 Oct 2026 07:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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 client_credentials token for the OAuth client that issued it, by presenting the user token as an OAuth 2.0 Bearer credential on a client_credentials grant request in place of the client’s configured secret. UAA’s client_credentials 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 client_id matches the request. A token obtained by a normal end user through a public authorization_code + PKCE flow — scoped only to uaa.user, carrying a user_id, and recording client_auth_method=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 client_credentials 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 client_credentials grant type on the same client_id — a non-default combination. Practical impact scales with the authorities assigned to that client. | |
| Title | UAA OAuth Token Endpoint Vulnerability allows user access token reuse for client_credentials grant type | |
| Weaknesses | CWE-287 | |
| References |
| |
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: vmware
Published:
Updated: 2026-10-06T14:34:25.951Z
Reserved: 2026-07-04T18:14:46.172Z
Link: CVE-2026-59358
Vulnrichment
Updated: 2026-10-06T14:34:21.269Z
NVD
Status : Awaiting Analysis
Published: 2026-10-06T07:16:59.460
Modified: 2026-10-06T16:00:36.547
Link: CVE-2026-59358
Redhat
No data.
OpenCVE Enrichment
Updated: 2026-10-06T08:30:18Z