CVE-2026-32762

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