Source
ghsa
Openshift Enterprise source-to-image before version 1.1.10 is vulnerable to an improper validation of user input. An attacker who could trick a user into using the command to copy files locally, from a pod, could override files outside of the target directory of the command.
GJSON < 1.6.6 allows attackers to cause a denial of service (panic: runtime error: slice bounds out of range) via a crafted GET call.
In Kubernetes, if the logging level is set to at least 9, authorization and bearer tokens will be written to log files. This can occur both in API server logs and client tool output like kubectl. This affects <= v1.19.3, <= v1.18.10, <= v1.17.13, < v1.20.0-alpha2.
In Kubernetes clusters using a logging level of at least 4, processing a malformed docker config file will result in the contents of the docker config file being leaked, which can include pull secrets or other registry credentials. This affects < v1.19.3, < v1.18.10, < v1.17.13.
HashiCorp go-slug before 0.5.0 does not address attempts at directory traversal involving ../ and symlinks.
All versions of the package semver-tags are vulnerable to Command Injection via the getGitTagsRemote function due to improper input sanitization.
An improper neutralization of input during web page generation ('Cross-site Scripting') [CWE-79] vulnerability in Sling App CMS version 1.1.4 and prior may allow an authenticated remote attacker to perform a reflected cross-site scripting (XSS) attack in multiple features. Upgrade to Apache Sling App CMS >= 1.1.6
Code Injection in GitHub repository froxlor/froxlor prior to 2.0.10.
`tokio::io::ReadHalf<T>::unsplit` can violate the `Pin` contract The soundness issue is described in the [tokio/issues#5372](https://github.com/tokio-rs/tokio/issues/5372) Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf) is unusual, combined with the difficulty of making any arbitrary use-after-free exploitable in Rust without doing a lot of careful alignment of data types in the surrounding code. The `tokio` feature `io-util` is also required to be enabled to trigger this soundness issue. Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e and carllerche appropriately responding and fixing the soundness bug. Tokio before 0.2.0 used `futures` 0.1 that did not have `Pin`, so it is not affected by this issue.
### Impact If JavaScript-based PayPal checkout methods are used (PayPal Plus, Smart Payment Buttons, SEPA, Pay Later, Venmo, Credit card), the amount and item list sent to PayPal may not be identical to the one in the created order. ### Patches The problem has been fixed with version 5.4.4 ### Workarounds Disable the aforementioned payment methods or use the Security Plugin in version >= 1.0.21. ### References [Shopware blog post](https://news.shopware.com/security-issue-in-paypal-plugin-update-required)