ghsa

### Impact When run in debug mode, Cilium may log sensitive information. In particular, Cilium running in debug mode will log the values of headers if they match HTTP network policy rules. This issue affects Cilium versions: - 1.7.* to 1.10.* inclusive - 1.11.* before 1.11.16 - 1.12.* before 1.12.9 - 1.13.* before 1.13.2 In addition, Cilium 1.12.* before 1.12.9 and 1.13.* before 1.13.2., when running in debug mode, might log secrets used by the Cilium agent. This includes TLS private keys for Ingress and GatewayAPI resources, depending on the configuration of the affected cluster. Output of the confidential data would occur at Cilium agent restart, when the secrets are modified, and on creation of Ingress or GatewayAPI resources. ### Patches This vulnerability is fixed in Cilium releases 1.11.16, 1.12.9, and 1.13.2. ### Workarounds Disable debug mode. ### Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special th...

### Impact Servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and a very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. A very large number of parts may cause the same problem. ### Patches Patched in Jetty versions * 9.4.51.v20230217 - via PR #9345 * 10.0.14 - via PR #9344 * 11.0.14 - via PR #9344 ### Workarounds Multipart parameter `maxRequestSize` must be set to a non-negative value, so the whole multipart content is limited (although still read...

### Impact `chainId` may be outdated if the user changes chains as part of the connection flow. This means that the value of `chainId` returned by `useWeb3React()` may be incorrect. In an application, this means that any data derived from `chainId` could be incorrect. For example, if a swapping application derives a wrapped token contract address from the `chainId` *and* a user has changed chains as part of their connection flow the application could cause the user to send funds to the incorrect address when wrapping. This is a common approach when using other foundational libraries like [`ethers`](https://github.com/ethers-io/ethers.js), and most users of v8 will want to upgrade past the affected versions. ### Patches Patched in https://github.com/Uniswap/web3-react/pull/749. Users of [email protected] should upgrade to at least: - @web3-react/coinbase-wallet@^8.0.35-beta.0 - @web3-react/eip1193@^8.0.27-beta.0 - @web3-react/metamask@^8.0.30-beta.0 - @web3-react/walletconne...

### Summary Strapi through 4.5.6 does not verify the access or ID tokens issued during the OAuth flow when the AWS Cognito login provider is used for authentication. ### Details Strapi through 4.5.6 does not verify the access or ID tokens issued during the OAuth flow when the AWS Cognito login provider is used for authentication. A remote attacker could forge an ID token that is signed using the 'None' type algorithm to bypass authentication and impersonate any user that use AWS Cognito for authentication. ### IoC Reviewing of application logs is recommended to detect any suspicious activity. Running the following regex pattern will extract all ID tokens sent to `/api/auth/cognito/callback`. `/\/api\/auth\/cognito\/callback\?[\s\S]*id_token=\s*([\S]*)/` Once you have a list of the ID tokens, you will need to verify each token using the public key file for your AWS Cognito user pool that you can download from `https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jw...

### 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.