CVE-2025-61772 in Rack
Summary
by MITRE • 10/07/2025
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` can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (`CRLFCRLF`). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS). Attackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected. Versions 2.2.19, 3.1.17, and 3.2.2 cap per-part header size (e.g., 64 KiB). As a workaround, restrict maximum request sizes at the proxy or web server layer (e.g., Nginx `client_max_body_size`).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/05/2025
The vulnerability identified as CVE-2025-61772 affects the Rack web server interface library for Ruby, specifically targeting versions prior to 2.2.19, 3.1.17, and 3.2.2. This issue resides within the `Rack::Multipart::Parser` component which processes multipart form data commonly used in web applications for file uploads and complex data submissions. The flaw represents a classic memory exhaustion vulnerability that can be exploited to cause denial of service conditions across affected applications. The vulnerability stems from inadequate input validation and memory management within the multipart parsing logic, creating a scenario where attacker-controlled data can trigger unbounded memory consumption.
The technical flaw manifests when the parser encounters multipart parts with headers that fail to properly terminate with the required blank line sequence CRLFCRLF. In normal operation, multipart headers should be properly delimited, but the vulnerable parser continues appending incoming data to memory without enforcing size limits on individual header blocks. This behavior creates a memory leak condition where each incomplete header can cause the parser to accumulate bytes indefinitely, with no mechanism to cap the growth of memory usage. The vulnerability is particularly dangerous because it can be triggered through carefully crafted requests that contain malformed multipart headers, making it difficult to distinguish from legitimate traffic patterns.
The operational impact of this vulnerability extends beyond simple resource exhaustion to potentially compromise entire application availability. When exploited, attackers can cause processes to consume all available memory, resulting in out-of-memory (OOM) conditions that force application termination or severe performance degradation. The severity scales significantly with both request size limits and concurrent connection handling, meaning that high-traffic applications face exponentially greater risk. This vulnerability affects any Ruby web application that processes multipart uploads, including content management systems, file sharing platforms, and web-based administrative interfaces. The attack vector is particularly insidious as it requires minimal privilege and can be executed through standard HTTP requests without authentication.
Mitigation strategies for CVE-2025-61772 include upgrading to the patched versions 2.2.19, 3.1.17, or 3.2.2 which implement per-part header size limits of 64 KiB to prevent unbounded memory accumulation. Organizations should prioritize patching their affected applications to ensure proper protection against this vulnerability. As a temporary workaround, administrators can implement request size restrictions at the reverse proxy or web server level, particularly through configurations like Nginx's client_max_body_size directive. This layered approach provides defense-in-depth while maintaining application functionality. The vulnerability aligns with CWE-400, which categorizes excessive resource consumption as a critical weakness in software design, and represents a common attack pattern documented in MITRE ATT&CK framework under the T1499 category for network denial of service. Organizations should also implement monitoring and alerting for unusual memory consumption patterns to detect potential exploitation attempts and maintain comprehensive incident response procedures for handling such security events.