| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| With Cloud Foundry Runtime cf-release versions v209 or earlier, UAA Standalone versions 2.2.6 or earlier and Pivotal Cloud Foundry Runtime 1.4.5 or earlier the change_email form in UAA is vulnerable to a CSRF attack. This allows an attacker to trigger an e-mail change for a user logged into a cloud foundry instance via a malicious link on a attacker controlled site. This vulnerability is applicable only when using the UAA internal user store for authentication. Deployments enabled for integration via SAML or LDAP are not affected. |
| An issue was discovered in Cloud Foundry Foundation cf-release v255 and Staticfile buildpack versions v1.4.0 - v1.4.3. A regression introduced in the Static file build pack causes the Staticfile.auth configuration to be ignored when the Static file file is not present in the application root. Applications containing a Staticfile.auth file but not a Static file had their basic auth turned off when an operator upgraded the Static file build pack in the foundation to one of the vulnerable versions. Note that Static file applications without a Static file are technically misconfigured, and will not successfully detect unless the Static file build pack is explicitly specified. |
| With Cloud Foundry Runtime cf-release versions v209 or earlier, UAA Standalone versions 2.2.6 or earlier and Pivotal Cloud Foundry Runtime 1.4.5 or earlier the UAA logout link is susceptible to an open redirect which allows an attacker to insert malicious web page as a redirect parameter. |
| 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. |
| The password change functionality in Cloud Foundry Runtime cf-release before 216, UAA before 2.5.2, and Pivotal Cloud Foundry (PCF) Elastic Runtime before 1.7.0 allow attackers to have unspecified impact by leveraging failure to expire existing sessions. |
| Cloud Foundry Runtime cf-release before 216, UAA before 2.5.2, and Pivotal Cloud Foundry (PCF) Elastic Runtime before 1.7.0 allow attackers to have unspecified impact by leveraging failure to expire password reset links. |
| 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. |
| 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. |
| 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. |
| With Cloud Foundry Runtime cf-release versions v208 or earlier, UAA Standalone versions 2.2.5 or earlier and Pivotal Cloud Foundry Runtime 1.4.5 or earlier, old Password Reset Links are not expired after the user changes their current email address to a new one. This vulnerability is applicable only when using the UAA internal user store for authentication. Deployments enabled for integration via SAML or LDAP are not affected. |
| 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. |
