ghsa

### Impact An attacker could sneak in a newline (`\n`) into both the header names and values. While the specification states that `\r\n\r\n` is used to terminate the header list, many servers in the wild will also accept `\n\n`. An attacker that is able to control the header names that are passed to Slilm-Psr7 would be able to intentionally craft invalid messages, possibly causing application errors or invalid HTTP requests being sent out with an PSR-18 HTTP client. The latter might present a denial of service vector if a remote service’s web application firewall bans the application due to the receipt of malformed requests. ### Patches The issue is patched in 1.6.1 ### Workarounds In Slim-Psr7 1.6.0 and below, validate HTTP header keys and/or values, and if using user-supplied values, filter them to strip off leading or trailing newline characters before calling withHeader(). ### Acknowledgments We are very grateful to and thank <a href="https://gjcampbell.co.uk/">Graham Campbe...

Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `"` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name `DISPLAY_LANGUAGE` and a value of `b; JSESSIONID=1337; c=d` instead of 3 separate cookies. ### Impact This has security implications because if, say, `JSESSIONID` is an `HttpOnly` cookie, and the `DISPLAY_LANGUAGE` cookie value is rendered on the page, an attacker can smuggle the `JSESSIONID` cookie into the `DISPLAY_LANGUAGE` cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by ...

### Impact We fixed with [CVE-2023-22731](https://github.com/shopware/platform/security/advisories/GHSA-93cw-f5jj-x85w) Twig filters to only be executed with allowed functions. It is possible to pass PHP Closures as string or an array and array crafted PHP Closures was not checked against allow list ### Patches The problem has been fixed with 6.4.20.1 with an improved override. ### Workarounds For older versions of 6.1, 6.2, and 6.3, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version. ### References https://docs.shopware.com/en/shopware-6-en/security-updates/security-update-04-2023?category=security-updates

### Impact A function in the implementation contract may be inaccessible if its selector clashes with one of the proxy's own selectors. Specifically, if the clashing function has a different signature with incompatible ABI encoding, the proxy could revert while attempting to decode the arguments from calldata. The probability of an accidental clash is negligible, but one could be caused deliberately. ### Patches The issue has been fixed in v4.8.3. ### Workarounds If a function appears to be inaccessible for this reason, it may be possible to craft the calldata such that ABI decoding does not fail at the proxy and the function is properly proxied through. ### References https://github.com/OpenZeppelin/openzeppelin-contracts/pull/4154

Affected versions of borsh cause undefined behavior when zero-sized-types (ZST) are parsed and the Copy/Clone traits are not implemented/derived. For instance if 1000 instances of a ZST are deserialized, and the ZST is not copy (this can be achieved through a singleton), then accessing/writing to deserialized data will cause a segmentation fault. There is currently no way for borsh to read data without also providing a Rust type. Therefore, if you are not using ZST for serialization, then you are not affected by this issue.

An issue was discovered in Mailman Core before 3.3.5. An attacker with access to the REST API could use timing attacks to determine the value of the configured REST API password and then make arbitrary REST API calls. The REST API is bound to localhost by default, limiting the ability for attackers to exploit this, but can optionally be made to listen on other interfaces.

Snowflake JDBC driver is vulnerable to command injection vulnerability via SSO URL authentication. The vulnerability was patched on March 17, 2023 as part of Snowflake JDBC driver Version 3.13.29. An attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution.

### Impact An attacker present in a room where an [MSC3401](https://github.com/matrix-org/matrix-spec-proposals/pull/3401) group call is taking place can eavesdrop on the video and audio of participants using matrix-js-sdk, without their knowledge. To affected matrix-js-sdk users, the attacker will not appear to be participating in the call. This attack is possible because matrix-js-sdk's group call implementation accepts incoming direct calls from other users, even if they have not yet declared intent to participate in the group call, as a means of resolving a race condition in call setup. Affected versions do not restrict access to the user's outbound media in this case. Legacy 1:1 calls are unaffected. ### Patches This is fixed in matrix-js-sdk 24.1.0. ### Workarounds Users may hold group calls in private rooms where only the exact users who are expected to participate in the call are present.

Image files uploaded in froxlor/froxlor prior to 2.0.14 were not properly validated which could result in remote code execution via path manipulation.

In Spring Session version 3.0.0, the session id can be logged to the standard output stream. This vulnerability exposes sensitive information to those who have access to the application logs and can be used for session hijacking. Specifically, an application is vulnerable if it is using HeaderHttpSessionIdResolver.