Cloud Foundry Loggregator, versions 89.x prior to 89.5 or 96.x prior to 96.1 or 99.x prior to 99.1 or 101.x prior to 101.9 or 102.x prior to 102.2, does not handle errors thrown while constructing certain http requests. A remote authenticated user may construct malicious requests to cause the traffic controller to leave dangling TCP connections, which could cause denial of service.

Cloud Foundry Loggregator, versions 89.x prior to 89.5 or 96.x prior to 96.1 or 99.x prior to 99.1 or 101.x prior to 101.9 or 102.x prior to 102.2, does not validate app GUID structure in requests. A remote authenticated malicious user knowing the GUID of an app may construct malicious requests to read from or write to the logs of that app.

Cloud Foundry Silk CNI plugin, versions prior to 0.2.0, contains an improper access control vulnerability. If the platform is configured with an application security group (ASG) that overlaps with the Silk overlay network, any applications can reach any other application on the network regardless of the configured routing policies.

Cloud Foundry Cloud Controller, versions prior to 1.52.0, contains information disclosure and path traversal vulnerabilities. An authenticated malicious user can predict the location of application blobs and leverage path traversal to create a malicious application that has the ability to overwrite arbitrary files on the Cloud Controller instance.

Cloud Foundry Diego, release versions prior to 2.8.0, does not properly sanitize file paths in tar and zip files headers. A remote attacker with CF admin privileges can upload a malicious buildpack that will allow a complete takeover of a Diego Cell VM and access to all apps running on that Diego Cell.

Cloud Foundry Foundation UAA, versions 4.12.X and 4.13.X, introduced a feature which could allow privilege escalation across identity zones for clients performing offline validation. A zone administrator could configure their zone to issue tokens which impersonate another zone, granting up to admin privileges in the impersonated zone for clients performing offline token validation.

In cf-deployment before 1.14.0 and routing-release before 0.172.0, the Cloud Foundry Gorouter mishandles WebSocket requests for AWS Application Load Balancers (ALBs) and some other HTTP-aware Load Balancers. A user with developer privileges could use this vulnerability to steal data or cause denial of service.

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.

Cloud Foundry routing-release, versions prior to 0.175.0, lacks sanitization for user-provided X-Forwarded-Proto headers. A remote user can set the X-Forwarded-Proto header in a request to potentially bypass an application requirement to only respond over secure connections.

Cloud Foundry Garden-runC, versions prior to 1.11.0, contains an information exposure vulnerability. A user with access to Garden logs may be able to obtain leaked credentials and perform authenticated actions using those credentials.

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.

Garden-runC prevents deletion of some app environments

Cloud Foundry Garden-runC release, versions prior to 1.16.1, prevents deletion of some app environments based on file attributes. A remote authenticated malicious user may create and delete apps with crafted file attributes to cause a denial of service for new app instances or scaling up of existing apps.

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.

In Garden versions 0.22.0-0.329.0, a vulnerability has been discovered in the garden-linux nstar executable that allows access to files on the host system. By staging an application on Cloud Foundry using Diego and Garden installations with a malicious custom buildpack an end user could read files on the host system that the BOSH-created vcap user has permissions to read and then package them into their app droplet.