Impact ONLY IMPACTS those use GitHub Status Notifications

Log output when updating GitHub status is improperly set to FULL always. It's recommended to apply the patch and rotate the GitHub token used for github status notifications. Given that this would output github tokens to a log system, the risk is slightly higher than a "low" since token exposure could grant elevated access to repositories outside of control. If using READ restricted tokens, the exposure is such that the token itself could be used to access resources otherwise restricted from reads.

Patches Patch is in progress. https://github.com/spinnaker/echo/pull/1316

Workarounds Disable GH Status Notifications. Filter your logs for Echo log data. Use read-only tokens that are limited in scope.

References sig-security in slack: https://spinnakerteam.slack.com/archives/CFN8F5UR2

Spinnaker is an open source, multi-cloud continuous delivery platform for releasing software changes, and Spinnaker's Rosco microservice produces machine images. Rosco prior to versions 1.29.2, 1.28.4, and 1.27.3 does not property mask secrets generated via packer builds. This can lead to exposure of sensitive AWS credentials in packer log files. Versions 1.29.2, 1.28.4, and 1.27.3 of Rosco contain fixes for this issue.

A workaround is available. It's recommended to use short lived credentials via role assumption and IAM profiles. Additionally, credentials can be set in /home/spinnaker/.aws/credentials and /home/spinnaker/.aws/config as a volume mount for Rosco pods vs. setting credentials in roscos bake config properties. Last even with those it's recommend to use IAM Roles vs. long lived credentials. This drastically mitigates the risk of credentials exposure. If users have used static credentials, it's recommended to purge any bake logs for AWS, evaluate whether AWSACCESSKEY, SECRETKEY and/or other sensitive data has been introduced in log files and bake job logs. Then, rotate these credentials and evaluate potential improper use of those credentials.

Spinnaker is an open source, multi-cloud continuous delivery platform. Spinnaker has improper permissions allowing pipeline creation & execution. This lets an arbitrary user with access to the gate endpoint to create a pipeline and execute it without authentication. If users haven't setup Role-based access control (RBAC) with-in spinnaker, this enables remote execution and access to deploy almost any resources on any account. Patches are available on the latest releases of the supported branches and users are advised to upgrade as soon as possible. Users unable to upgrade should enable RBAC on ALL accounts and applications. This mitigates the ability of a pipeline to affect any accounts. Block application access unless permission are enabled. Users should make sure ALL application creation is restricted via appropriate wildcards.

Spinnaker is an open source, multi-cloud continuous delivery platform. A path traversal vulnerability was discovered in uses of TAR files by AppEngine for deployments. This uses a utility to extract files locally for deployment without validating the paths in that deployment don't override system files. This would allow an attacker to override files on the container, POTENTIALLY introducing a MITM type attack vector by replacing libraries or injecting wrapper files. Users are advised to update as soon as possible. For users unable to update disable Google AppEngine deployments and/or disable artifacts that provide TARs.

Nolan Ray from Apple Information Security identified a security vulnerability in Spinnaker, all versions prior to version 1.23.4, 1.22.4 or 1.21.5. The vulnerability exists within the handling of SpEL expressions that allows an attacker to read and write arbitrary files within the orca container via authenticated HTTP POST requests.