Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing
21Vexday Risk Score
No sign of exploitation. No public exploitation artifact known so far.
ssvc Trackcvss 7.5epss 0.6%
exploitation probability
0.6%top 54% of all CVEs
observed exploitation
nono source reports it
In short
Rack web servers can be crashed by sending very large form data requests that consume all available memory. An attacker can exploit this by submitting oversized URL-encoded forms, causing the server to run out of memory and stop responding.
Technical detail
Rack::Request#POST in versions prior to 2.2.20, 3.1.18, and 3.2.3 performs unbounded buffering of application/x-www-form-urlencoded request bodies via rack.input.read(nil), lacking enforced size limits. An unauthenticated remote attacker can send a large POST request with Content-Type: application/x-www-form-urlencoded to exhaust server memory and trigger denial of service. Mitigation requires upgrading to patched versions and enforcing body size limits at the proxy/web server layer.
Summary generated and translated by AI from the official description.
Rack is a modular Ruby web server interface. Prior to versions 2.2.20, 3.1.18, and 3.2.3, `Rack::Request#POST` 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 (DoS) through memory exhaustion. Users should upgrade to Rack version 2.2.20, 3.1.18, or 3.2.3, anu of which enforces form parameter limits using `query_parser.bytesize_limit`, preventing unbounded reads of `application/x-www-form-urlencoded` bodies. Additionally, enforce strict maximum body size at the proxy or web server layer (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H