CVE-2026-59357: Self-UAA OIDC Configuration allows JWT injection to establish unauthorized sessions
Insufficient verification of data authenticity (CWE-345) in the external OIDC login callback in Cloud Foundry UAA v4.5.0 to v79.6.0 (inclusive) allows an authenticated UAA user to bypass the OAuth authorization-code exchange and establish an authenticated external-OIDC browser session, via submitting a UAA access token or a cross-client ID token as the callback’s idtoken parameter.
The issue only manifests when a UAA zone is configured with an OIDC identity provider whose issuer exactly matches that zone’s own /oauth/token endpoint (a “self-UAA” OIDC configuration). In this configuration, the callback takes a supplied idtoken directly instead of requiring the authorization code exchange, and does not verify that the token was actually issued as an ID token for the specific self-OIDC relying-party client. An attacker holding any valid UAA JWT for themselves — including a plain access token with only uaa.user scope, or a valid ID token issued to an unrelated client such as cf — can present it as the callback’s idtoken and be authenticated into a mapped local (“shadow”) account. Because the resulting session is not verified against the originating token’s true audience or userid, its effective privilege depends entirely on the shadow account’s group memberships, which can include administrative scopes such as clients.write.
Exploitation requires a valid UAA user JWT, a valid browser login state for the target zone, and the presence of a self-referential OIDC provider configuration — this is not a pre-authentication vulnerability, and does not by itself grant privileges beyond those already held by the mapped shadow account.
Affected Software
Event History
Frequently Asked Questions
Which UAA deployments are affected?
Affected deployments run Cloud Foundry UAA versions 4.5.0 through 79.6.0 inclusive and have an OIDC identity provider in a UAA zone whose issuer exactly matches that zone's own /oauth/token endpoint. The issue manifests only in this self-UAA OIDC configuration.
What does an attacker need to exploit this issue?
The attacker must already be an authenticated UAA user and possess a valid UAA JWT for their own account. A plain access token with the uaa.user scope or an ID token issued to an unrelated client, such as cf, can be supplied as the callback id_token.
How can I determine whether a zone is exposed?
Review each zone's OIDC identity-provider configuration and check whether its issuer is exactly the same as that zone's /oauth/token endpoint. A matching issuer indicates a self-UAA OIDC configuration subject to this issue.