ghsa

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

### 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/blob/v2.2.13/lib/rack/session/abstract/id.rb#L263-L270) 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`, or - Ensure your appl...

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Craft CMS stores arbitrary content provided by unauthenticated users in session files. This content could be accessed and executed, possibly using an independent vulnerability. Craft CMS redirects requests that require authentication to the login page and generates a session file on the server at `/var/lib/php/sessions`. Such session files are named `sess_[session_value]`, where `[session_value]` is provided to the client in a `Set-Cookie` response header. Craft CMS stores the return URL requested by the client without sanitizing parameters. Consequently, an unauthenticated client can introduce arbitrary values, such as PHP code, to a known local file location on the server. Craft CMS versions 5.7.5 and 4.15.3 have been released to address this issue.