CVE-2026-125109

In Rack prior to 2.2.25, 3.1.23, and 3.2.8, Rack::Multipart::Parser can retain parsed data in its internal StringScanner buffer when reads end inside or immediately after multipart headers. An unauthenticated attacker can align many small parts with rack.multipart.buffer_size boundaries so the buffer grows with the request despite per-field, header, and preamble limits, causing a worker to exhaust memory.

Rack is a modular Ruby web server interface. Prior to 2.2.25, 3.1.23, and 3.2.8, Rack::Static serves a path after Utils.clean_path_info normalization but evaluates header_rules against a path that is only URL-decoded. An unauthenticated attacker can request a known file through raw or percent-encoded dot segments and receive it without path-specific security headers such as Content-Disposition or Content-Security-Policy.

In Rack, Rack::Multipart::Parser.parse_boundary can skip a leading empty or quoted boundary parameter in a multipart Content-Type header and accept a later parameter. Rack can therefore parse a request body with a boundary a conforming intermediary would not derive, allowing form fields or file uploads to reach an application without intended proxy or WAF inspection. The issue is fixed in versions 2.2.25, 3.1.23, and 3.2.8.

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.