Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing

An attacker can exploit this vulnerability by sending a large POST request with the application/x-www-form-urlencoded Content-Type. The Rack framework, without proper length or memory limits, reads the entire request body into memory. This can quickly exhaust available memory resources, leading to a denial of service. The impact is significant as it can render the application unresponsive, potentially disrupting services and impacting users. The severity stems from the ease of triggering the vulnerability – simply crafting a large POST request is sufficient. This is similar to other memory exhaustion vulnerabilities where attackers can leverage oversized inputs to crash services.

Applications and services relying on the Ruby Rack framework, particularly those handling user-supplied data via POST requests, are at risk. This includes web applications, APIs, and microservices built with Ruby on Rails or other Rack-based frameworks. Shared hosting environments where Rack is used are also particularly vulnerable, as an attacker could potentially exploit this vulnerability through a compromised application on the same server.

• ruby / server:

ps aux | grep rack

• ruby / server:

journalctl -u rack -f | grep "read(nil)"

• generic web: Use a WAF or proxy to monitor for unusually large POST requests (Content-Length > 1MB) with Content-Type: application/x-www-form-urlencoded.

1. 2025-10-10Disclosure

   disclosure

1. Réservé2025-10-03
2. Publiée2025-10-10
3. Modifiée2026-02-04
4. EPSS mis à jour2026-03-23

The primary mitigation for CVE-2025-61919 is to upgrade to Rack version 2.2.20 or later, which includes a fix for this memory exhaustion issue. If upgrading is not immediately feasible, consider implementing a reverse proxy or WAF with request size limits. Configure the proxy or WAF to reject requests exceeding a reasonable size threshold (e.g., 1MB or 2MB) for application/x-www-form-urlencoded requests. Additionally, review application code to ensure it handles large POST requests gracefully and doesn't rely on unbounded memory allocation. After upgrading, confirm the fix by sending a large POST request and verifying that the application does not crash or exhibit signs of memory exhaustion.