CVE-2026-59357 in UAA
Summary
by MITRE • 10/06/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The identified vulnerability represents a critical failure in data authenticity verification within the Cloud Foundry User Account and Authentication service, specifically affecting versions ranging from v4.5.0 through v79.6.0. This flaw is categorized under CWE-345, which denotes insufficient verification of data authenticity. The core technical defect resides in the external OpenID Connect login callback mechanism when operating within a specific configuration known as self-UAA OIDC. In this setup, a UAA zone is configured with an identity provider whose issuer URL exactly matches its own OAuth token endpoint. Under normal operational circumstances, such configurations are intended to streamline authentication by allowing direct token acceptance rather than forcing the standard authorization code exchange flow. However, the implementation fails to rigorously validate that the submitted ID token was actually issued for the specific relying-party client associated with this OIDC provider. Consequently, an attacker can bypass the strict OAuth2 authorization-code exchange protocol and directly inject a UAA access token or a cross-client ID token into the callback’s id_token parameter. This manipulation allows the system to accept tokens that were not intended for this specific authentication context, effectively treating any valid user JWT as a legitimate credential for establishing a session.
The operational impact of this vulnerability is significant because it enables an authenticated UAA user to escalate their privileges by leveraging shadow accounts. When an attacker presents a valid token—whether it be a plain access token with minimal scopes like uaa.user or an ID token issued to an unrelated client such as cf—the system authenticates the request and maps the identity to a local shadow account within the target zone. Crucially, the resulting session is not verified against the originating token’s true audience claims or user identifiers. This disconnect means that the effective privileges granted to the attacker are determined solely by the group memberships of the mapped shadow account rather than the permissions inherent in the presented token. If the shadow account possesses administrative capabilities, such as clients.write scope, an attacker can gain control over application client configurations and potentially compromise other applications hosted on the Cloud Foundry platform. This bypasses standard access controls because the system trusts the structural validity of the JWT without validating its contextual appropriateness for the specific OIDC provider configuration.
From a threat modeling perspective, this vulnerability aligns with MITRE ATT&CK techniques related to credential manipulation and privilege escalation via identity federation flaws. The attack requires three distinct conditions: possession of a valid UAA user JSON Web Token, an active browser login state within the target zone, and the presence of a self-referential OIDC provider configuration on the server. It is important to note that this is not a pre-authentication vulnerability; it does not allow anonymous access or bypass initial login screens directly without prior authentication context. Furthermore, it does not inherently grant privileges beyond those already associated with the mapped shadow account’s group memberships. However, in many enterprise deployments, shadow accounts are provisioned with broad permissions to facilitate seamless integration between identity providers and platform services. Therefore, while the attack vector is constrained by these prerequisites, the potential for lateral movement and administrative takeover remains high if such configurations exist within the infrastructure.
Mitigation strategies must focus on correcting the validation logic in the external OIDC login callback. The system should enforce strict audience verification to ensure that any ID token presented during this flow was explicitly issued for the relying-party client associated with the self-UAA configuration. Additionally, implementing state parameter checks and ensuring that tokens are validated against their intended issuer and audience claims will prevent the reuse of cross-client or unrelated access tokens in this context. Administrators should review their OIDC provider configurations to identify any instances where the identity provider’s issuer matches the UAA zone’s token endpoint. If such self-referential configurations are not strictly necessary, they should be removed or reconfigured to use distinct issuers. For environments that must retain these configurations, applying the vendor-provided security patches for versions above v79.6.0 is essential to resolve the underlying validation deficiency and restore proper integrity checks on incoming authentication tokens.