CVE-2026-59357
Self-UAA OIDC Configuration allows JWT injection to establish unauthorized sessions
Published Oct 6, 2026
CVSS 4.0 · 6.5 Medium
EPSS < 1%
KEV · Not listed
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.
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.
Affected Products
-
CVE record
-
NVD configurations
No data
-
Red Hat packages
No data
-
OpenCVE enrichment
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Cloud Foundry | UAA | affected |
|
|||||||||
| Cloud Foundry | cf-deployment | affected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Cloudfoundry | Cf-deployment |
|
||||||||||||
| Cloudfoundry | Uaa |
|
Remediation
Tracking
Advisories
Metrics
Attack Vector Network
Attack Complexity Low
Privileges Required None
Attack Requirements Present
User Interaction Active
Vulnerable System Confidentiality Impact High
Vulnerable System Integrity Impact High
Vulnerable System Availability Impact None
Subsequent System Confidentiality Impact None
Subsequent System Integrity Impact None
Subsequent System Availability Impact None
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.185% probability within 30 days)
Exploitation none
Automatable no
Technical Impact total
References
History
Oct 9, 2026 8:15 AM
First appearance in the feed. Affected vendors updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Cloudfoundry
Cloudfoundry cf-deployment Cloudfoundry uaa |
|
| Vendors & Products |
Cloudfoundry
Cloudfoundry cf-deployment Cloudfoundry uaa |
Oct 6, 2026 12:30 PM
Scoring metrics updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Oct 6, 2026 7:15 AM
Description updated. Title updated. Weaknesses updated. Added references. Scoring metrics updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | Self-UAA OIDC Configuration allows JWT injection to establish unauthorized sessions | |
| Weaknesses | CWE-345 | |
| References |
| |
| Metrics |
cvssV4_0
|
Subscriptions
Weaknesses
