CVE-2025-61770: Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)
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:
ruby @sbuf.scanuntil(@bodyregex)
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.
Other sources
Rack is a modular Ruby web server interface. In versions prior to 2.2.19, 3.1.17, and 3.2.2, 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. 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. Versions 2.2.19, 3.1.17, and 3.2.2 enforce a preamble size limit (e.g., 16 KiB) or discard preamble data entirely. Workarounds include limiting total request body size at the proxy or web server level and monitoring memory and set per-process limits to prevent OOM conditions.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rubygems/rackto a version that resolves this vulnerability.Fixed in 3.2.2 - Upgrade
Upgrade
rubygems/rackto a version that resolves this vulnerability.Fixed in 3.1.17 - Upgrade
Upgrade
rubygems/rackto a version that resolves this vulnerability.Fixed in 2.2.19 - Upgrade
Upgrade
Rack (Rack::Multipart::Parser)to a version that resolves this vulnerability.Fixed in 2.2.19 - Upgrade
Upgrade
Rack (Rack::Multipart::Parser)to a version that resolves this vulnerability.Fixed in 3.1.17 - Upgrade
Upgrade
Rack (Rack::Multipart::Parser)to a version that resolves this vulnerability.Fixed in 3.2.2 - Compensating control
Limit total request body size at the proxy or web server level to reduce the amount of data that can be sent before the multipart boundary is found.
- Compensating control
Monitor memory and set per-process limits to prevent OOM conditions caused by large multipart preambles.
Event History
Frequently Asked Questions
What is the severity of CVE-2025-61770?
CVE-2025-61770 is considered a high severity vulnerability due to the potential for denial of service attacks through excessive memory usage.
How do I mitigate CVE-2025-61770?
To mitigate CVE-2025-61770, upgrade Rack to version 2.2.19, 3.1.17, or 3.2.2, where the vulnerability has been addressed.
What versions are affected by CVE-2025-61770?
CVE-2025-61770 affects Rack versions prior to 2.2.19, 3.1.17, and 3.2.2.
Can CVE-2025-61770 lead to data loss?
CVE-2025-61770 primarily poses a risk of denial of service rather than direct data loss.
What is the nature of CVE-2025-61770?
CVE-2025-61770 allows a client to cause excessive memory consumption by sending a large multipart preamble during requests.