CVE-2023-27530

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.