ghsa

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

Versions of the package asyncua before 0.9.96 are vulnerable to Denial of Service (DoS) such that an attacker can send a malformed packet and as a result, the server will enter into an infinite loop and consume excessive memory.

Versions of the package asyncua before 0.9.96 are vulnerable to Improper Authentication such that it is possible to access Address Space without encryption and authentication. **Note:** This issue is a result of missing checks for services that require an active session.

All versions of the package static-server are vulnerable to Directory Traversal due to improper input sanitization passed via the validPath function of server.js.

### Impact A security vulnerability in Soft Serve could allow an unauthenticated, remote attacker to bypass public key authentication when keyboard-interactive SSH authentication is active, through the `allow-keyless` setting, and the public key requires additional client-side verification for example using FIDO2 or GPG. This is due to insufficient validation procedures of the public key step during SSH request handshake, granting unauthorized access if the keyboard-interaction mode is utilized. An attacker could exploit this vulnerability by presenting manipulated SSH requests using keyboard-interactive authentication mode. This could potentially result in unauthorized access to the Soft Serve. ### Patches Users should upgrade to the latest Soft Serve version `v0.6.2` to receive the patch for this issue. ### Workarounds To workaround this vulnerability without upgrading, users can _temporarily_ disable Keyboard-Interactive SSH Authentication using the `allow-keyless` setting. #...

### Summary Autoinstrumentation out of the box adds the label `http_method` that has unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent. ### Details HTTP method for requests can be easily set by an attacker to be random and long. ### PoC Send many requests with long randomly generated HTTP methods and observe how memory consumption increases during it. The app can be like [this example from the official docs](https://opentelemetry-python-contrib.readthedocs.io/en/latest/instrumentation/flask/flask.html#id1). ### Impact In order to be affected program has to be instrumented for HTTP handlers and does not filter any unknown HTTP methods on the level of CDN, LB, previous middleware, etc. ### Proposed solution For convenience and safe usage of this library, it should by default mark with the label `UNKNOWN` non-standard HTTP methods to show that such requests were made (and this way does not increase cardinality). In case som...