Rack vulnerabilities

Rack, a modular Ruby web server interface, prior to versions 2.2.22, 3.1.20, and 3.2.5, generates an HTML directory index where each file entry is a clickable link. If a file exists on disk whose basename starts with the javascript: scheme (e.g., javascript:alert(1)), the generated anchor's href is exactly javascript:alert(1), allowing JavaScript execution when clicked.

Rack::Request incorrectly parses the Host header, accepting characters like /, ?, #, and @ that are not allowed in RFC-compliant hostnames. The req.host method returns the full unvalidated value, allowing bypass of host validation based on simple prefix or suffix checks.

Rack versions from 3.0.0.beta1 to 3.1.20 and 3.2.0 to 3.2.5 have a DoS vulnerability in the multipart parser. An unauthenticated attacker can send a crafted multipart/form-data request with many parts containing long escaped parameter values, causing excessive CPU usage during parsing.

Rack before versions 3.1.21 and 3.2.6 incorrectly parses the Forwarded header (RFC 7239) by splitting on semicolons before handling quoted-string values. Since quoted values may contain semicolons, the header can be interpreted as multiple Forwarded directives, allowing attackers to smuggle host, proto, for, or by parameters.

Rack::Multipart::Parser incorrectly unfolds folded multipart headers, preserving CRLF in parameter values. This can lead to header injection or HTTP response splitting in applications using these values.

In the Rack library (modular Ruby web server interface) versions prior to 2.2.23, 3.1.21, and 3.2.6, the Rack::Files#fail method sets the Content-Length header using String#size instead of String#bytesize. When the response body contains multibyte UTF-8 characters, the declared length is smaller than the actual bytes sent. An attacker can trigger this mismatch by requesting a non-existent path with percent-encoded UTF-8 characters, leading to incorrect HTTP response framing and potential response desynchronization in deployments relying on the wrong Content-Length value.

In Rack prior to versions 2.2.23, 3.1.21, and 3.2.6, a vulnerability was found in Rack::Sendfile#map_accel_path. Injecting the X-Accel-Mapping header into a regular expression without proper escaping allows an attacker to control the X-Accel-Redirect header, potentially leading to serving unauthorized files via nginx.

Rack prior to versions 2.2.23, 3.1.21, and 3.2.6 does not limit the size of data in multipart/form-data requests without a Content-Length header. An attacker can send an arbitrarily large file, causing disk space exhaustion and denial of service (DoS).

Rack before versions 2.2.23, 3.1.21, and 3.2.6 has a denial of service vulnerability due to an unlimited number of byte ranges in the HTTP Range header. An attacker can supply many small overlapping ranges, causing disproportionate CPU, memory, I/O, and bandwidth consumption.

Rack::Static incorrectly evaluates header rules on the raw URL-encoded PATH_INFO, while the file is served after decoding. A request for an encoded variant of a path can bypass the intended security headers.

Rack versions before 2.2.23, 3.1.21, and 3.2.6 improperly validate URL prefixes in Rack::Static, potentially leading to unauthorized static file serving and information disclosure.

Rack::Directory interpolates the configured root path directly into a regular expression when deriving the displayed directory path. If the root contains regex metacharacters such as +, *, or ., the prefix stripping can fail and the generated directory listing may expose the full filesystem path in the HTML output.

In the Rack interface (versions before 2.2.23, 3.1.21, and 3.2.6), a DoS vulnerability exists in the Rack::Utils.select_best_encoding method. An unauthenticated attacker can send a request with a crafted Accept-Encoding header, causing excessive CPU consumption by Rack::Deflater.

A multipart content smuggling vulnerability was found in Rack (Ruby) before versions 2.2.23, 3.1.21, and 3.2.6. Rack selects the last boundary parameter instead of the first, which can bypass WAF filters.

A vulnerability in the Rack library allows bypassing directory access restrictions through path manipulation. The `Rack::Directory` path check uses a prefix match, enabling access outside the configured root, e.g., via a request like `/../root_example/`. The issue is fixed in versions 2.2.22, 3.1.20, and 3.2.5.

Rack versions prior to 2.2.20, 3.1.18, and 3.2.3 reads the entire request body into memory for Content-Type: application/x-www-form-urlencoded, calling rack.input.read(nil) without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service through memory exhaustion.

An information disclosure vulnerability in Rack::Sendfile when running behind a proxy that supports x-sendfile headers (e.g., Nginx). Specially crafted x-sendfile-type and x-accel-mapping headers are interpreted as proxy configuration directives, potentially triggering unintended internal requests that bypass proxy-level access restrictions.

A vulnerability in Rack (versions prior to 2.2.19, 3.1.17, and 3.2.2) in Rack::Multipart::Parser. When a multipart part's header block never terminates with the required blank line (CRLFCRLF), the parser appends incoming bytes to memory without a size cap. A remote attacker can send incomplete multipart headers to exhaust memory and cause a denial of service (DoS) via process termination (OOM) or severe slowdown.

In Rack before versions 2.2.19, 3.1.17, and 3.2.2, 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 can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service.

A vulnerability in Rack (versions prior to 2.2.19, 3.1.17, and 3.2.2) in Rack::Multipart::Parser. The parser buffers the entire multipart preamble (bytes before the first boundary) in memory without any size limit. A client can send a large preamble, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions.

In Rack before version 2.2.18, Rack::QueryParser enforces its params_limit only for parameters separated by '&', while still splitting on both '&' and ';'. Attackers could use ';' separators to bypass the parameter count limit and submit more parameters than intended.

A DoS vulnerability exists in Rack <v3.0.4.2, <v2.2.6.3, <v2.1.4.3 and <v2.0.9.3 within the Multipart MIME parsing code, allowing an attacker to craft requests that cause multipart parsing to take longer than expected.