ADVISORIES
GEM
SEVERITY
CVSS v3.x: 7.5 (High)
PATCHED VERSIONS
- ~> 2.2.20
- ~> 3.1.18
- >= 3.2.3
DESCRIPTION
Summary
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.
Details
When handling non-multipart form submissions, Rack’s request parser performs:
form_vars = get_header(RACK_INPUT).read
Since read
is called with no argument, the entire request body is
loaded into a Ruby String
. This occurs before query parameter
parsing or enforcement of any params_limit
. As a result, Rack
applications without an upstream body-size limit can experience
unbounded memory allocation proportional to request size.
Impact
Attackers can send large application/x-www-form-urlencoded
bodies
to consume process memory, causing slowdowns or termination by the
operating system (OOM). The effect scales linearly with request
size and concurrency. Even with parsing limits configured, the
issue occurs before those limits are enforced.
Mitigation
- Update to a patched version of Rack that enforces form parameter
limits using
query_parser.bytesize_limit
, preventing unbounded reads ofapplication/x-www-form-urlencoded
bodies. - Enforce strict maximum body size at the proxy or web server layer
(e.g., Nginx
client_max_body_size
, ApacheLimitRequestBody
).
RELATED
- https://github.com/rack/rack/security/advisories/GHSA-6xw4-3v39-52mm
- https://github.com/rack/rack/commit/4e2c903991a790ee211a3021808ff4fd6fe82881
- https://github.com/rack/rack/commit/cbd541e8a3d0c5830a3c9a30d3718ce2e124f9db
- https://github.com/rack/rack/commit/e179614c4a653283286f5f046428cbb85f21146f
- https://github.com/advisories/GHSA-6xw4-3v39-52mm