An unsafe default behavior in Rack::QueryParser allows bypass of the params_limit parameter count restriction when query string parameters are delimited by semicolons (;) rather than ampersands (&). The parser counts only & when enforcing the limit, while still splitting on both & and ;. As a result, an attacker can supply a crafted HTTP query using ; delimiters to exceed the intended parameter count, potentially causing performance degradation or exhaustion of resources (denial of service).

Rack::Multipart::Parser buffers the entire multipart preamble (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions.

Rack::Multipart::Parser stores non-file form fields (parts without a `filename`) entirely in memory as Ruby `String` objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS). Attackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead.

Rack::Multipart::Parser can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (`CRLFCRLF`). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS). Attackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency.

A memory-exhaustion vulnerability exists in Rack when parsing application/x-www-form-urlencoded request bodies. Rack::Request#POST reads the entire request body into memory without enforcing a maximum length or cap. Attackers can exploit this by sending large form submissions, potentially causing denial of service (DoS) through memory exhaustion. Even with configured parsing limits, the issue occurs before those limits are enforced, allowing unbounded memory allocation proportional to request size.