CVE-2026-59357
MediumCVSS 6.5Exploitation Probability (EPSS)
Low risk7th percentile - higher than 7% of all known CVEs
Summary
A vulnerability in Cloud Foundry UAA (versions 4.5.0 to 79.6.0) stems from insufficient verification of data authenticity in the external OIDC login callback. It allows an authenticated UAA user to bypass the OAuth authorization-code exchange and establish an authenticated external-OIDC browser session by submitting a valid UAA JWT as the callback's id_token parameter.
Risk Assessment
An attacker with a valid JWT (e.g., an access token with uaa.user scope) can gain access to a mapped local (shadow) account with administrative privileges if that account has groups like clients.write. This could lead to unauthorized changes in UAA configuration.
Recommendation
Immediately upgrade Cloud Foundry UAA to a version newer than 79.6.0 if possible. Additionally, review OIDC configurations for self-UAA identity providers and consider disabling or changing them to mitigate the risk.
Other vulnerabilities in Cloud Foundry UAA
See all- CVE-2017-4963High
An issue was discovered in Cloud Foundry affecting versions v252 and earlier, as well as UAA versions from v2.0.0 to v2.7.4.12 and from v3.0.0 to v3.11.0. UAA is vulnerable to session fixation when configured to authenticate against external SAML or OpenID Connect based identity providers.
- CVE-2017-4960High
An issue was discovered in Cloud Foundry release v247 through v252 and UAA release v3.9.0 through v3.11.0 that may lead to a denial of service attack on UAA OAuth clients.
- CVE-2016-6659High
Cloud Foundry and UAA versions before 248; UAA 2.x before 2.7.4.12, 3.x before 3.6.5, and 3.7.x through 3.9.x before 3.9.3 have a vulnerability that allows attackers to gain privileges by accessing UAA logs and subsequently running a specially crafted application that interacts with a configured SAML provider.
- CVE-2026-40965Critical
Cloud Foundry UAA versions v76.12.0 through v78.12.0 inadvertently expose EC private keys through the public /token_keys endpoint. The vulnerability affects only deployments using EC keys for JWT token signing.
- CVE-2026-59358High
A vulnerability in Cloud Foundry UAA's OAuth token endpoint allows an authenticated attacker with 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 a Bearer credential on a client_credentials grant request. UAA fails to verify that the Bearer credential is actually a client credential, accepting any valid access token with a matching client_id.
- CVE-2026-59335High
Improper handling of case sensitivity (CWE-178) in the identity zone authorization check in the Identity Zone Endpoint in Cloud Foundry UAA allows a remote authenticated attacker holding only the zones.write authority to bypass the intended restriction that this authority does not grant access to the privileged uaa (system) identity zone, by referring to the zone identifier in a non-lowercase form (e.g. UAA) in the request path and body. The authorization layer performs a case-sensitive comparison against the system zone identifier, while the underlying MySQL persistence layer resolves identifiers case-insensitively under its default collation, so the request is authorized incorrectly and is then resolved against the real system zone record. This allows the attacker to overwrite the system zone's JWT signing key with attacker-controlled key material, forge JWTs claiming the admin client and administrator scopes, and fully compromise UAA and any Cloud Foundry deployment that trusts it. This issue only affects UAA deployments backed by MySQL using its default collation; PostgreSQL and HSQLDB backends are not affected.
Original NVD description (English source)
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 id_token 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 id_token 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 id_token and be authenticated into a mapped local (“shadow”) account. Because the resulting session is not verified against the originating token’s true audience or user_id, 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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS