Search
Search Results (16 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-59358 | 1 Cloudfoundry | 2 Cf-deployment, Uaa | 2026-10-09 | N/A |
| Improper authentication (CWE-287) in the OAuth token endpoint in Cloud Foundry UAA allows a remote, authenticated attacker holding a valid user access token to obtain a fully-privileged client_credentials token for the OAuth client that issued it, by presenting the user token as an OAuth 2.0 Bearer credential on a client_credentials grant request in place of the client’s configured secret. UAA’s client_credentials handling does not verify that the Bearer credential supplied for client authentication is actually a client credential (a client secret or a valid configured client authentication method); it accepts any valid access token whose client_id matches the request. A token obtained by a normal end user through a public authorization_code + PKCE flow — scoped only to uaa.user, carrying a user_id, and recording client_auth_method=none — satisfies this check. That user token cannot itself administer OAuth clients (POST /oauth/clients correctly returns 403), but when replayed as Bearer authentication on a client_credentials request for the same client, UAA issues a new client-only token carrying the client’s full authorities, such as clients.write. An attacker can use that token to create arbitrary new OAuth clients, including clients with attacker-chosen authorities, without ever possessing the client’s actual secret. Exploitation requires a valid user access token (the attacker’s own) for a client that is configured to support both a public, user-facing authorization flow and the client_credentials grant type on the same client_id — a non-default combination. Practical impact scales with the authorities assigned to that client. | ||||
| CVE-2026-59357 | 1 Cloudfoundry | 2 Cf-deployment, Uaa | 2026-10-09 | N/A |
| 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. | ||||
| CVE-2026-47839 | 1 Cloudfoundry | 2 Cf-deployment, Uaa | 2026-09-13 | N/A |
| A vulnerability allows users authenticating through a federated OIDC provider to obtain the uaa.admin scope despite operators restricting that provider through externalGroupsWhitelist configuration. The issue occurs specifically when an OIDC identity provider uses groupMappingMode: AS_SCOPES with a wildcard externalGroupsWhitelist entry. | ||||
| CVE-2026-47840 | 1 Cloudfoundry | 2 Cf-deployment, Uaa | 2026-08-03 | 7.5 High |
| A network attacker positioned between UAA and its LDAP directory can impersonate the directory using any certificate from any trusted CA, then harvest the LDAP bind password and every end-user password sent during simple-bind authentication, and return forged group memberships that grant themselves admin scopes. This affects every deployment that authenticates users against LDAP over StartTLS. Affected versions: UAA versions prior to v78.13.0; Cf-deployment versions prior to v56.2.0. | ||||
| CVE-2026-41005 | 1 Cloudfoundry | 2 Cf-deployment, Uaa | 2026-06-12 | 9 Critical |
| Cloud Foundry UAA incorrectly treated XML encryption to the Service Provider (confidentiality) as a substitute for XML signatures from the Identity Provider (authenticity) in two SAML flows: the OAuth 2.0 SAML2 bearer grant (token endpoint) and browser SSO (ACS) when wantAssertionSigned is set to false. Assertions or responses that were unsigned but contained encrypted content could still be accepted. Encryption uses the SP's public key from published metadata, therefore, any party, not only a trusted IdP, can produce ciphertext UAA can decrypt; successful decryption therefore does not prove the IdP issued the message. Affected versions: Cloud Foundry UAA (uaa_release) 2.0.0 through 78.13.0. Cloud Foundry CF Deployment all versions through 56.1.0. | ||||
| CVE-2026-40965 | 1 Cloudfoundry | 2 Cf-deployment, Uaa-release | 2026-06-02 | 10 Critical |
| Cloud Foundry UAA versions v76.12.0 through v78.12.0 are vulnerable to a private key exposure. The server contains a vulnerability where EC (Elliptic Curve) private keys are inadvertently exposed through the public /token_keys endpoint. This endpoint is designed to provide public key material for JWT token verification but incorrectly exposes private key components for EC keys. The vulnerability affects deployments using EC keys for JWT token signing. The vulnerability does not affect RSA key configurations, only deployments using EC keys for JWT signing. Affected versions: - uaa_release: v76.12.0 through v78.12.0 (inclusive); fixed in v78.13.0 or later - CF Deployment: v30.0.0 through v56.0.0 (inclusive); fixed in v56.1.0 or later (bundles uaa_release v78.13.0) | ||||
| CVE-2026-22723 | 1 Cloudfoundry | 3 Cf-deployment, Uaa, Uaa-release | 2026-05-10 | 6.5 Medium |
| Inappropriate user token revocation due to a logic error in the token revocation endpoint implementation in Cloudfoundry UAA v77.30.0 to v78.7.0 and in Cloudfoundry Deployment v48.7.0 to v54.10.0. | ||||
| CVE-2026-22734 | 1 Cloudfoundry | 2 Cf-deployment, Uaa | 2026-04-17 | 8.6 High |
| Cloud Foundry UUA is vulnerable to a bypass that allows an attacker to obtain a token for any user and gain access to UAA-protected systems. This vulnerability exists when SAML 2.0 bearer assertions are enabled for a client, as the UAA accepts SAML 2.0 bearer assertions that are neither signed nor encrypted. This issue affects UUA from v77.30.0 to v78.7.0 (inclusive) and it affects CF Deployment from v48.7.0 to v54.14.0 (inclusive). | ||||
| CVE-2025-22246 | 1 Cloudfoundry | 2 Cf-deployment, Uaa Release | 2025-07-11 | 3 Low |
| Cloud Foundry UAA release versions from v77.21.0 to v7.31.0 are vulnerable to a private key exposure in logs. | ||||
| CVE-2017-8031 | 1 Cloudfoundry | 2 Cf-release, Uaa-release | 2025-04-20 | 5.3 Medium |
| An issue was discovered in Cloud Foundry Foundation cf-release (all versions prior to v279) and UAA (30.x versions prior to 30.6, 45.x versions prior to 45.4, 52.x versions prior to 52.1). In some cases, the UAA allows an authenticated user for a particular client to revoke client tokens for other users on the same client. This occurs only if the client is using opaque tokens or JWT tokens validated using the check_token endpoint. A malicious actor could cause denial of service. | ||||
| CVE-2016-0732 | 2 Cloudfoundry, Pivotal | 4 Cf-release, Uaa-release, User Account And Authentication and 1 more | 2025-04-20 | 8.8 High |
| The identity zones feature in Pivotal Cloud Foundry 208 through 229; UAA 2.0.0 through 2.7.3 and 3.0.0; UAA-Release 2 through 4, when configured with multiple identity zones; and Elastic Runtime 1.6.0 through 1.6.13 allows remote authenticated users with privileges in one zone to gain privileges and perform operations on a different zone via unspecified vectors. | ||||
| CVE-2019-3801 | 1 Cloudfoundry | 3 Cf-deployment, Credhub, Uaa Release | 2024-11-21 | 9.8 Critical |
| Cloud Foundry cf-deployment, versions prior to 7.9.0, contain java components that are using an insecure protocol to fetch dependencies when building. A remote unauthenticated malicious attacker could hijack the DNS entry for the dependency, and inject malicious code into the component. | ||||
| CVE-2019-3788 | 1 Cloudfoundry | 1 Uaa Release | 2024-11-21 | N/A |
| Cloud Foundry UAA Release, versions prior to 71.0, allows clients to be configured with an insecure redirect uri. Given a UAA client was configured with a wildcard in the redirect uri's subdomain, a remote malicious unauthenticated user can craft a phishing link to get a UAA access code from the victim. | ||||
| CVE-2019-3775 | 1 Cloudfoundry | 1 Uaa Release | 2024-11-21 | N/A |
| Cloud Foundry UAA, versions prior to v70.0, allows a user to update their own email address. A remote authenticated user can impersonate a different user by changing their email address to that of a different user. | ||||
| CVE-2019-11279 | 1 Cloudfoundry | 1 Uaa Release | 2024-11-21 | 8.8 High |
| CF UAA versions prior to 74.1.0 can request scopes for a client that shouldn't be allowed by submitting an array of requested scopes. A remote malicious user can escalate their own privileges to any scope, allowing them to take control of UAA and the resources it controls. | ||||
| CVE-2018-1190 | 2 Cloudfoundry, Pivotal | 3 Cf-release, Uaa, Uaa Bosh | 2024-11-21 | N/A |
| An issue was discovered in these Pivotal Cloud Foundry products: all versions prior to cf-release v270, UAA v3.x prior to v3.20.2, and UAA bosh v30.x versions prior to v30.8 and all other versions prior to v45.0. A cross-site scripting (XSS) attack is possible in the clientId parameter of a request to the UAA OpenID Connect check session iframe endpoint used for single logout session management. | ||||
Page 1 of 1.