ghsa

dialect/mod.rs in the libsql-sqlite3-parser crate through 0.13.0 before 14f422a for Rust can crash if the input is not valid UTF-8.

inner::drop in inner.rs in the wgp crate through 0.2.0 for Rust lacks drop_slow thread synchronization.

lib.rs in the trailer crate through 0.1.2 for Rust mishandles allocating with a size of zero.

### Original Report In Eclipse Jetty versions 12.0.0 to 12.0.16 included, an HTTP/2 client can specify a very large value for the HTTP/2 settings parameter SETTINGS_MAX_HEADER_LIST_SIZE. The Jetty HTTP/2 server does not perform validation on this setting, and tries to allocate a ByteBuffer of the specified capacity to encode HTTP responses, likely resulting in OutOfMemoryError being thrown, or even the JVM process exiting. ### Impact Remote peers can cause the JVM to crash or continuously report OOM. ### Patches 12.0.17 ### Workarounds No workarounds. ### References https://github.com/jetty/jetty.project/issues/12690

In Eclipse Jetty versions 9.4.0 to 9.4.56 a buffer can be incorrectly released when confronted with a gzip error when inflating a request body. This can result in corrupted and/or inadvertent sharing of data between requests.

OpenStack Ironic before 29.0.1 can write unintended files to a target node disk during image handling (if a deployment was performed via the API). A malicious project assigned as a node owner can provide a path to any local file (readable by ironic-conductor), which may then be written to the target node disk. This is difficult to exploit in practice, because a node deployed in this manner should never reach the ACTIVE state, but it still represents a danger in environments running with non-default, insecure configurations such as with automated cleaning disabled. The fixed versions are 24.1.3, 26.1.1, and 29.0.1.

`FastMap::get()` lacks sufficient checks to its parameter index and is used to unsafely get a `Vec` element. `fast_id_map` is unmaintained.

### Impact The Trix editor, in versions prior to 2.1.15, is vulnerable to XSS attacks when pasting malicious code. An attacker could trick a user to copy and paste malicious code that would execute arbitrary JavaScript code within the context of the user's session, potentially leading to unauthorized actions being performed or sensitive information being disclosed. ### Patches Update Recommendation: Users should upgrade to Trix editor version 2.1.15 or later. ### References The XSS vulnerability was reported by HackerOne researcher [hiumee](https://hackerone.com/hiumee?type=user).

## Summary `Rack::QueryParser` parses query strings and `application/x-www-form-urlencoded` bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters. ## Details The vulnerability arises because `Rack::QueryParser` iterates over each `&`-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing. ## Impact An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted. ## Mitigation - Update to a version of Rack that limits the number of parameters parsed, or - ...

## Summary When using the `Rack::Session::Pool` middleware, simultaneous rack requests can restore a deleted rack session, which allows the unauthenticated user to occupy that session. ## Details [Rack session middleware](https://github.com/rack/rack-session/blob/v2.1.0/lib/rack/session/abstract/id.rb#L271-L278) prepares the session at the beginning of request, then saves is back to the store with possible changes applied by host rack application. This way the session becomes to be a subject of race conditions in general sense over concurrent rack requests. ## Impact When using the `Rack::Session::Pool` middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout. ## Mitigation - Update to the latest version of `rack-session`, or - Ensu...