Track vulnerabilities like this one. Sign up free to get alerted when software you use is affected.
6.5

CVE-2026-59357: Cloud Foundry UAA allows unauthorized login via token

CVE-2026-59357 · published 4 days ago
Summary

The UAA component in Cloud Foundry versions 4.5.0 through 79.6.0 can accept a forged token during a special OIDC setup and create a logged‑in session without the normal code exchange. An attacker who already has a valid UAA token could use it to sign in as another user, potentially gaining administrative rights. Apply the latest security update or reconfigure the OIDC provider to avoid the self‑referencing setup.

What to do

The CVE record does not list a fixed version. Check the vendor's site or the advisory links below - a fix may already be released.

Affected software
VendorProductAffected versions
cloud foundry uaa <= 79.6.0
cloud foundry cf-deployment <= 60.4.0
Original advisory text
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 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.
Fix within
Internet-facing 14 days
Internal At next upgrade
  • Not known to be exploited
  • Needs hands-on effort to exploit
  • Gives an attacker full control
Severity
6.5 Medium
Exploitation
<1% chance of attack within 30 days
Type
CWE-345Insufficient Verification of Data Authenticity
Timeline
Published6 Oct 2026
Updated9 Oct 2026
First seen6 Oct 2026
Sources
CVE-2026-59357 · MITRE
Track software like this
Free during beta