CVE’s

Cloud Foundry Routing (Gorouter) versions prior to 0.206.0 allow a malicious developer with "cf push" access to cause denial-of-service to the CF cluster by pushing an app that returns specially crafted HTTP responses that crash the Gorouters.

RabbitMQ versions 3.8.x prior to 3.8.7 are prone to a Windows-specific binary planting security vulnerability that allows for arbitrary code execution. An attacker with write privileges to the RabbitMQ installation directory and local access on Windows could carry out a local binary hijacking (planting) attack and execute arbitrary code.

Cloud Foundry CAPI (Cloud Controller) versions prior to 1.98.0 allow authenticated users having only the "cloud_controller.read" scope, but no roles in any spaces, to list all droplets in all spaces (whereas they should see none).

Cloud Foundry CAPI (Cloud Controller), versions prior to 1.97.0, when used in a deployment where an app domain is also the system domain (which is true in the default CF Deployment manifest), were vulnerable to developers maliciously or accidentally claiming certain sensitive routes, potentially resulting in the developer's app handling some requests that were expected to go to certain system components.

Cloud Foundry Routing (Gorouter), versions prior to 0.204.0, when used in a deployment with NGINX reverse proxies in front of the Gorouters, is potentially vulnerable to denial-of-service attacks in which an unauthenticated malicious attacker can send specially-crafted HTTP requests that may cause the Gorouters to be dropped from the NGINX backend pool.

Concourse, versions prior to 6.3.1 and 6.4.1, in installations which use the GitLab auth connector, is vulnerable to identity spoofing by way of configuring a GitLab account with the same full name as another user who is granted access to a Concourse team. GitLab groups do not have this vulnerability, so GitLab users may be moved into groups which are then configured in the Concourse team.

VMware Tanzu Application Service for VMs (2.7.x versions prior to 2.7.19, 2.8.x versions prior to 2.8.13, and 2.9.x versions prior to 2.9.7) contains an App Autoscaler that logs the UAA admin password. This credential is redacted on VMware Tanzu Operations Manager; however, the unredacted logs are available to authenticated users of the BOSH Director. This credential would grant administrative privileges to a malicious user. The same versions of App Autoscaler also log the App Autoscaler Broker password. Prior to newer versions of Operations Manager, this credential was not redacted from logs. This credential allows a malicious user to create, delete, and modify App Autoscaler services instances. Operations Manager started redacting this credential from logs as of its versions 2.7.15, 2.8.6, and 2.9.1. Note that these logs are typically only visible to foundation administrators and operators.

Spring Integration framework provides Kryo Codec implementations as an alternative for Java (de)serialization. When Kryo is configured with default options, all unregistered classes are resolved on demand. This leads to the "deserialization gadgets" exploit when provided data contains malicious code for execution during deserialization. In order to protect against this type of attack, Kryo can be configured to require a set of trusted classes for (de)serialization. Spring Integration should be proactive against blocking unknown "deserialization gadgets" when configuring Kryo in code.

Spring Cloud Netflix, versions 2.2.x prior to 2.2.4, versions 2.1.x prior to 2.1.6, and older unsupported versions allow applications to use the Hystrix Dashboard proxy.stream endpoint to make requests to any server reachable by the server hosting the dashboard. A malicious user, or attacker, can send a request to other servers that should not be exposed publicly.

When configured to enable default typing, Jackson contained a deserialization vulnerability that could lead to arbitrary code execution. Jackson fixed this vulnerability by blacklisting known "deserialization gadgets". Spring Batch configures Jackson with global default typing enabled which means that through the previous exploit, arbitrary code could be executed if all of the following is true: * Spring Batch's Jackson support is being leveraged to serialize a job's ExecutionContext. * A malicious user gains write access to the data store used by the JobRepository (where the data to be deserialized is stored). In order to protect against this type of attack, Jackson prevents a set of untrusted gadget classes from being deserialized. Spring Batch should be proactive against blocking unknown "deserialization gadgets" when enabling default typing.