Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)

The core issue lies in the Rack::Multipart::Parser's handling of the multipart preamble. The parser buffers the entire preamble in memory without enforcing a size limit. A malicious client can craft a request with an exceptionally large preamble, followed by a valid boundary. This excessive memory consumption can lead to an out-of-memory (OOM) condition, resulting in the Rack application process crashing or becoming unresponsive. The blast radius extends to any application relying on Rack for handling multipart requests, potentially impacting multiple services and users. This vulnerability is similar to other memory exhaustion attacks where an attacker overwhelms a system's resources to cause a denial of service.

Applications built using the Ruby Rack framework, particularly those handling file uploads or other multipart data, are at risk. This includes web applications, APIs, and services that rely on Rack for request processing. Systems with older Rack versions (≤2.2.9) are particularly vulnerable.

• ruby / server:

ps aux | grep -i rack | grep -i multipart

• ruby / server:

journalctl -u your_rack_app -g 'memory exhaustion' --since '1h'

• generic web: Use a WAF to monitor for unusually large multipart requests (Content-Length header exceeding a reasonable threshold).

1. 2025-10-07Disclosure

   disclosure

1. आरक्षित2025-09-30
2. प्रकाशित2025-10-07
3. संशोधित2026-02-04
4. EPSS अद्यतन2026-03-23

The primary mitigation is to upgrade to Rack version 2.2.19 or later, which includes a fix for this vulnerability. If an immediate upgrade is not feasible, consider implementing temporary workarounds. One approach is to configure the web server or application to limit the maximum request size for multipart uploads. Another potential mitigation involves using a WAF (Web Application Firewall) to filter requests with excessively large multipart preambles. Monitor application logs for signs of memory exhaustion or process crashes, which could indicate exploitation attempts. After upgrade, confirm by sending a test multipart request with a large preamble and verifying that the application does not crash.