| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An issue was discovered in Cloud Foundry Foundation cf-release versions prior to v261; UAA release 2.x versions prior to v2.7.4.17, 3.6.x versions prior to v3.6.11, 3.9.x versions prior to v3.9.13, and other versions prior to v4.2.0; and UAA bosh release (uaa-release) 13.x versions prior to v13.15, 24.x versions prior to v24.10, 30.x versions prior to 30.3, and other versions prior to v37. There is privilege escalation (arbitrary password reset) with user invitations. |
| 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. |
| The Cloud Controller and Router in Cloud Foundry (CAPI-release capi versions prior to v1.32.0, Routing-release versions prior to v0.159.0, CF-release versions prior to v267) do not validate the issuer on JSON Web Tokens (JWTs) from UAA. With certain multi-zone UAA configurations, zone administrators are able to escalate their privileges. |
| An issue was discovered in the Cloud Controller API in Cloud Foundry Foundation CAPI-release versions after v1.6.0 and prior to v1.35.0 and cf-release versions after v244 and prior to v268. A carefully crafted CAPI request from a Space Developer can allow them to gain access to files on the Cloud Controller VM for that installation. |
| In Cloud Foundry capi-release versions 1.33.0 and later, prior to 1.42.0 and cf-release versions 268 and later, prior to 274, the original fix for CVE-2017-8033 introduces an API regression that allows a space developer to execute arbitrary code on the Cloud Controller VM by pushing a specially crafted application. NOTE: 274 resolves the vulnerability but has a serious bug that is fixed in 275. |
| A path traversal vulnerability was identified in the Cloud Foundry component Cloud Controller that affects cf-release versions prior to v208 and Pivotal Cloud Foundry Elastic Runtime versions prior to 1.4.2. Path traversal is the 'outbreak' of a given directory structure through relative file paths in the user input. It aims at accessing files and directories that are stored outside the web root folder, for disallowed reading or even executing arbitrary system commands. An attacker could use a certain parameter of the file path for instance to inject '../' sequences in order to navigate through the file system. In this particular case a remote authenticated attacker can exploit the identified vulnerability in order to upload arbitrary files to the server running a Cloud Controller instance - outside the isolated application container. |
| Cloud Foundry Runtime cf-release before 216, UAA before 2.5.2, and Pivotal Cloud Foundry (PCF) Elastic Runtime before 1.7.0 allow remote attackers to conduct cross-site request forgery (CSRF) attacks on PWS and log a user into an arbitrary account by leveraging lack of CSRF checks. |
| Gorouter in Cloud Foundry cf-release v141 through v228 allows man-in-the-middle attackers to conduct cross-site scripting (XSS) attacks via vectors related to modified requests. |
| 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. |
| It was discovered that cf-release v231 and lower, Pivotal Cloud Foundry Elastic Runtime 1.5.x versions prior to 1.5.17 and Pivotal Cloud Foundry Elastic Runtime 1.6.x versions prior to 1.6.18 do not properly enforce disk quotas in certain cases. An attacker could use an improper disk quota value to bypass enforcement and consume all the disk on DEAs/CELLs causing a potential denial of service for other applications. |
| In Cloud Controller versions prior to 1.46.0, cf-deployment versions prior to 1.3.0, and cf-release versions prior to 283, Cloud Controller accepts refresh tokens for authentication where access tokens are expected. This exposes a vulnerability where a refresh token that would otherwise be insufficient to obtain an access token, either due to lack of client credentials or revocation, would allow authentication. |
| 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. |
| Applications in cf-release before 245 can be configured and pushed with a user-provided custom buildpack using a URL pointing to the buildpack. Although it is not recommended, a user can specify a credential in the URL (basic auth or OAuth) to access the buildpack through the CLI. For example, the user could include a GitHub username and password in the URL to access a private repo. Because the URL to access the buildpack is stored unencrypted, an operator with privileged access to the Cloud Controller database could view these credentials. |
| Cloud Foundry Cloud Controller, capi-release versions prior to 1.0.0 and cf-release versions prior to v237, contain a business logic flaw. An application developer may create an application with a route that conflicts with a platform service route and receive traffic intended for the service. |
| Applications deployed to Cloud Foundry, versions v166 through v227, may be vulnerable to a remote disclosure of information, including, but not limited to environment variables and bound service details. For applications to be vulnerable, they must have been staged using automatic buildpack detection, passed through the Java Buildpack detection script, and allow the serving of static content from within the deployed artifact. The default Apache Tomcat configuration in the affected java buildpack versions for some basic web application archive (WAR) packaged applications are vulnerable to this issue. |
