ghsa

Pillow versions before v10.0.1 bundled libwebp binaries in wheels that are vulnerable to CVE-2023-5129 (previously CVE-2023-4863). Pillow v10.0.1 upgrades the bundled libwebp binary to v1.3.2.

### Impact The vulnerability occurs in configurations where foreign content is allowed, i.e. either `svg` or `math` are in the list of allowed elements. Specifically, the requirements for the vulnerability are: 1. Allowing one foreign element: `svg`, or `math` 2. Comments or one raw text element: `iframe`, `noembed`, `xmp`, `title`, `noframes`, `style` or `noscript` Configurations that meet the above requirements plus the following are vulnerable to an additional vulnerability: - Any HTML integration element: `title`, `desc`, `mi`, `mo`, `mn`, `ms`, `mtext`, `annotation-xml`. In case an application sanitizes user input with a vulnerable configuration, an attacker could bypass the sanitization and inject arbitrary HTML, including JavaScript code. Note that in the default configuration the vulnerability is not present. ### Patches The vulnerability has been fixed in versions 8.0.723 and 8.1.722-beta (preview version). ### Workarounds Disallow foreign elements `svg` and `math`. ...

### Impact The title property, available on most Zope objects, can be used to store script code that is executed while viewing the affected object in the Zope Management Interface (ZMI) because the title property is displayed unquoted in the breadcrumbs element. All versions of Zope 4 and Zope 5 are affected. ### Patches Patches will be released with Zope versions 4.8.11 and 5.8.6 ### Workarounds Make sure only Manager users can edit and view Zope objects in the Zope Management Interface. This is the default.

femanager fails to check access permissions for the invitation component. Depending on the configuration of the plugin, a remote user can create frontend user accounts with access to configured frontend groups.

### Impact API servers running `express-zod-api` having: - version of `express-zod-api` below `10.0.0-beta1`, - and using the following (or similar) validation schema in its implementation: `z.string().email()`, are vulnerable to a DoS attack due to: - Inefficient Regular Expression Complexity in `zod` versions up to `3.22.2`, - depending on `zod`. ### Patches The patched version of `zod` fixing the vulnerability is `3.22.3`. However, it's highly recommended to upgrade `express-zod-api` to at least version `10.0.0`, which does not depend on `zod` strictly and directly, but requires its installation as a peer dependency instead, enabling you to install the patched `zod` version yourself. ### Workarounds When it's not possible to upgrade your dependencies, consider the following replacement in your implementation: ```diff - z.string().email() + z.string().regex( + /^(?!\.)(?!.*\.\.)([A-Z0-9_+-\.]*)[A-Z0-9_+-]@([A-Z0-9][A-Z0-9\-]*\.)+[A-Z]{2,}$/i + ) ``` This regular express...

### Impact For some in-circuit values, it is possible to construct two valid decomposition to bits. In addition to the canonical decomposition of `a`, for small values there exists a second decomposition for `a+r` (where `r` is the modulus the values are being reduced by). The second decomposition was possible due to overflowing the field where the values are defined. Internally, the comparison methods `frontend.API.Cmp` and `frontend.API.IsLess` used binary decomposition and checked the bitwise differences. This allows a malicious prover to construct a valid proof for a statement `a < b` even if `a > b`. The issue impacts all users using `API.Cmp` or `API.IsLess` methods. Additionally, it impacts the users using `bits.ToBinary` or `API.ToBinary` methods if full-width decomposition is requested (the default behaviour if no options are given). The issues does not impact comparison methods in field emulation (package `std/math/emulated`) and dedicated comparison package (`std/math/cm...

A flaw was found in Quarkus. Quarkus OIDC can leak both ID and access tokens in the authorization code flow when an insecure HTTP protocol is used, which can allow attackers to access sensitive user data directly from the ID token or by using the access token to access user data from OIDC provider services. Please note that passwords are not stored in access tokens.

Netty-handler has been found to no validate hostnames when using TLS in its default configuration. As a result netty-handler is vulnerable to man-in-the-middle attacks. Users would need to set the protocol to "HTTPS" in the SSLParameters of the SSLEngine to opt in to host name validation. A change in default behavior is expected in the `5.x` release branch with no backport planned. In the interim users are advised to enable host name validation in their configurations. See https://github.com/netty/netty/issues/8537 for details on the forthcoming change in default behavior.

### Summary Presto JDBC is vulnerable to Server-Side Request Forgery (SSRF) when connecting a remote Presto server. An attacker can modify the nextUri parameter to internal server in response content that Presto JDBC client will request next and view sensitive information from highly sensitive internal servers or perform a local port scan. ### Details The Presto protocol has a nextUri parameter that specifies which URI the client will request next to obtain more query data. Presto JDBC will directly use the nextUri returned by the remote Presto server as the URL for the next request. So if a malicious server modify the nextUri parameter to the internal server, JDBC will request it and cause SSRF. For unexpected responses, JDBC will put the response body into the error. So the response of the internal server will be leaked if the server also returns the error directly to the user. The relevant code is in file path `/presto-client/src/main/java/com/facebook/presto/client/StatementC...

### Summary Presto JDBC is vulnerable to Server-Side Request Forgery (SSRF) when connecting a remote Presto server. An attacker can construct a redirect response that Presto JDBC client will follow and view sensitive information from highly sensitive internal servers or perform a local port scan. ### Details Presto JDBC client uses OkHttp to send `POST /v1/statement` and `GET /v1/info` requests to the remote Presto server. And OkHttp will follow 301 and 302 redirect by default. In addition, JDBC will manually follow 307 and 308 redirect. Therefore, if a malicious server returns a 30x redirect, JDBC client will follow the redirect and cause SSRF. For unexpected responses, JDBC will put the response body into the error. So the response of the internal server will be leaked if the server also returns the error directly to the user. The relevant code is in file path `/presto-client/src/main/java/com/facebook/presto/client/StatementClientV1.java` and function `StatementClientV1` . T...