{"id":"CVE-2026-59357","title":"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 establis…","summary":"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 establis…","severity":"medium","cvss":6.5,"cvssVector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:P","cwe":["CWE-345"],"vendor":"Cloud Foundry","product":"UAA","affected":["UAA >= 4.5.0 <= 79.6.0","cf-deployment <= 60.4.0"],"published":"2026-10-06","updated":"2026-10-06","sourceUpdated":"2026-10-06T07:16:59.253","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-59357","references":[{"url":"https://www.cloudfoundry.org/blog/cve-2026-59357-self-uaa-oidc-configuration-allows-jwt-injection-to-establish-unauthorized-sessions/","label":"security@vmware.com"}],"tags":["nvd","cve.org"],"cvssSource":"cna","ingestedAt":"2026-10-06T07:49:23.044Z","slug":"CVE-2026-59357","body":"## Overview\n\nInsufficient 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.\n\n\n\nThe 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.\n\n\n\nExploitation 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.\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":36,"depthScoreParts":{"impact":35.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}