ghsa

Uncontrolled Resource Consumption vulnerability in Apache Commons Configuration 1.x. There are a number of issues in Apache Commons Configuration 1.x that allow excessive resource consumption when loading untrusted configurations or using unexpected usage patterns. The Apache Commons Configuration team does not intend to fix these issues in 1.x. Apache Commons Configuration 1.x is still safe to use in scenarios where you only load trusted configurations. Users that load untrusted configurations or give attackers control over usage patterns are recommended to upgrade to the 2.x version line, which fixes these issues. Apache Commons Configuration 2.x is not a drop-in replacement, but as it uses a separate Maven groupId and Java package namespace they can be loaded side-by-side, making it possible to do a gradual migration.

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