Cloud Foundry UAA EUVD-2026-92988

The target OAuth client must be configured to support BOTH a public, user-facing authorization flow (authorization_code + PKCE, client_auth_method=none) AND the client_credentials grant type on the same client_id - the vendor explicitly identifies this as a non-default combination. The attacker must hold a valid user access token for that client, obtainable through normal end-user login (their own token scoped to uaa.user). The user token alone cannot administer clients (POST /oauth/clients returns 403); escalation occurs only when it is replayed as Bearer client authentication. Limiting factors: authenticated user access is required (PR:L), the dual-grant client configuration is non-default, and practical impact scales with the authorities assigned to the affected client (a low-authority client yields limited impact).

The CVSS 4.0 score of 7.6 (High) is driven by high confidentiality and integrity impact (VC:H/VI:H) from an attacker being able to mint fully-privileged client tokens and create arbitrary OAuth clients. However, several signals temper real-world urgency. The vector requires PR:L (a valid authenticated user token) and, critically, AT:P - a 'present' attack requirement that corresponds directly to the vendor's statement that the vulnerable client must be configured for BOTH a public authorization_code+PKCE flow AND the client_credentials grant on the same client_id, which the vendor explicitly calls a non-default combination. No EPSS score, CISA KEV listing, or public exploit was provided in the input, so there is no evidence of active or at-scale exploitation; exploitation status is 'no public exploit identified at time of analysis.' This is a genuine authentication-logic flaw (CWE-287) with a clear privilege-escalation path, but its practical priority is gated by a non-default deployment condition rather than being a broadly exploitable internet-facing issue. Note the input provides only a CVSS 4.0 vector (no 3.1 vector) and no EPSS/KEV/POC data, so widespread-exploitation likelihood cannot be quantified from available signals; impact also scales entirely with the authorities assigned to the affected client, which is deployment-specific.

A legitimate end user of an application obtains their own user access token through the normal public authorization_code + PKCE login flow for an OAuth client that also permits the client_credentials grant. They replay that user token as the OAuth 2.0 Bearer client credential on a client_credentials request for the same client_id, and UAA - failing to verify the credential is actually a client secret - returns a client-only token carrying the client's full authorities such as clients.write. The attacker then uses that token to register new OAuth clients with attacker-chosen authorities. No public exploit identified at time of analysis.