Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)

The primary impact of CVE-2025-61772 is a denial of service. An attacker can craft a specially designed multipart request that causes the Rack::Multipart::Parser to continuously append data to memory without any size limits. This unbounded memory allocation can quickly exhaust available resources, leading to application crashes, service unavailability, and potentially impacting other services sharing the same infrastructure. The attack is relatively simple to execute, requiring only the ability to send HTTP requests. Successful exploitation could disrupt critical web applications relying on Rack, potentially causing significant operational downtime.

Applications built using the Ruby Rack framework, particularly those handling file uploads or multipart form data, are at risk. Shared hosting environments where multiple applications share the same Rack instance are especially vulnerable, as one application's exploitation could impact others. Legacy applications using older Rack versions are also at increased risk.

• ruby / server: Monitor Rack process memory usage using tools like ps or top. Look for sudden spikes in memory consumption.

ps aux | grep rack | grep -v grep | awk '{print $6}' | sort -n

• ruby / server: Examine application logs for errors related to memory allocation or parsing multipart requests. • generic web: Use curl to send a crafted multipart request with a missing CRLF terminator and observe the server's response and resource usage.

curl -F '[email protected]' -F 'header=some_header' http://your-rack-app/upload

• ruby / server: Use a Ruby debugger to step through the Rack::Multipart::Parser code and observe the memory allocation behavior when processing malformed multipart requests.

1. 2025-10-07Disclosure

   disclosure

1. 已保留2025-09-30
2. 发布日期2025-10-07
3. 修改日期2026-02-04
4. EPSS 更新日期2026-03-23

The recommended mitigation for CVE-2025-61772 is to upgrade to Rack version 2.2.19 or later, which includes a fix for the unbounded memory allocation. If upgrading is not immediately feasible, consider implementing input validation to reject multipart requests with excessively long header blocks. Web Application Firewalls (WAFs) can be configured to filter requests with unusually large header sizes. Monitoring memory usage on the affected systems is also crucial to detect potential DoS attacks. While a direct detection signature is difficult, monitoring for unusually high memory consumption by the Rack process is a viable workaround.