Cloud Foundry UAA CVE-2026-59357

Three concrete prerequisites must all hold: (1) the target UAA zone must be configured with an external OIDC identity provider whose issuer exactly matches that same zone's own /oauth/token endpoint - the non-default 'self-UAA' OIDC configuration that triggers the callback to accept a supplied id_token without the authorization-code exchange; (2) the attacker must possess any valid UAA JWT for themselves, including a plain access token with only uaa.user scope or an ID token issued to an unrelated client such as cf; and (3) the attacker needs a valid browser login state for the target zone. Limiting factors: this is not pre-authentication (a valid UAA user is required), it requires active user/browser interaction (UI:A), and it does not by itself grant privileges beyond those of the mapped shadow account - effective impact depends entirely on that account's group memberships. Environments without a self-referential OIDC provider configuration are not exploitable.

This is a genuine but conditional, mid-severity privilege/authentication flaw rather than a mass-exploitation emergency. The strongest signal is the narrow precondition: the bug only manifests when a UAA zone is configured with a 'self-UAA' OIDC identity provider whose issuer exactly matches that zone's own /oauth/token endpoint - a non-default, relatively uncommon configuration. There is a notable CONFLICT in the authentication signal: the supplied CVSS 4.0 vector asserts PR:N (no privileges required), yet the description explicitly states 'allows an authenticated UAA user', 'Exploitation requires a valid UAA user JWT', and 'this is not a pre-authentication vulnerability.' The PR:N is therefore inconsistent with the described exploitation model; the attacker must already hold a valid UAA JWT (even a low-scope uaa.user token), so this should be treated as an authenticated, not pre-auth, issue - verify with the vendor/NVD. The vector's AT:P (attack requirements present) and UI:A partially capture the required self-OIDC configuration and the need for a valid browser login state, which better reflect real-world difficulty. Impact is high (VC:H/VI:H) but bounded: the session inherits only the mapped shadow account's group memberships, so escalation to administrative scopes such as clients.write is possible only where the shadow account already carries them. No EPSS score and no KEV listing were provided, so there is no evidence of active or widespread exploitation; the vector's E:P (exploit maturity: proof-of-concept) is the only exploit-maturity signal and does not equate to in-the-wild use. Net: patch in affected environments, but prioritize behind true unauthenticated-RCE issues, and prioritize especially where self-UAA OIDC providers are in use.

An attacker who already has a low-privilege UAA account (e.g. only uaa.user scope) in a zone configured with a self-referential OIDC provider obtains any valid UAA JWT for themselves - a plain access token or an ID token issued to an unrelated client such as cf. They submit that token directly as the external OIDC login callback's id_token parameter, skipping the OAuth authorization-code exchange, and are authenticated into a mapped local shadow account whose group memberships may carry higher privileges. The CVSS exploit maturity marker (E:P) indicates proof-of-concept-level maturity, but no public exploit code was provided in the references.