---
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'
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.