ADVISORIES
GEM
SEVERITY
CVSS v3.x: 7.5 (High)
PATCHED VERSIONS
- ~> 2.2.19
- ~> 3.1.17
- >= 3.2.2
DESCRIPTION
Summary
Rack::Multipart::Parser
buffers the entire multipart preamble
(bytes before the first boundary) in memory without any size limit.
A client can send a large preamble followed by a valid boundary,
causing significant memory use and potential process termination
due to out-of-memory (OOM) conditions.
Details
While searching for the first boundary, the parser appends incoming
data into a shared buffer (@sbuf.concat(content)
) and scans for
the boundary pattern:
@sbuf.scan_until(@body_regex)
If the boundary is not yet found, the parser continues buffering data indefinitely. There is no trimming or size cap on the preamble, allowing attackers to send arbitrary amounts of data before the first boundary.
Impact
Remote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to garbage collection.
Mitigation
-
Upgrade: Use a patched version of Rack that enforces a preamble size limit (e.g., 16 KiB) or discards preamble data entirely per RFC 2046 § 5.1.1.
-
Workarounds:
- Limit total request body size at the proxy or web server level.
- Monitor memory and set per-process limits to prevent OOM conditions.
RELATED
- https://nvd.nist.gov/vuln/detail/CVE-2025-61770
- https://github.com/rack/rack/security/advisories/GHSA-p543-xpfm-54cp
- https://github.com/rack/rack/commit/589127f4ac8b5cf11cf88fb0cd116ffed4d2181e
- https://github.com/rack/rack/commit/d869fed663b113b95a74ad53e1b5cae6ab31f29e
- https://github.com/rack/rack/commit/e08f78c656c9394d6737c022bde087e0f33336fd
- https://github.com/advisories/GHSA-p543-xpfm-54cp