CVE-2025-49007

What it actually does

Crafted Content-Disposition headers trigger catastrophic backtracking during parsing in Rack versions 3.1.0 through 3.1.15, consuming excessive CPU time on multipart request handling and enabling denial of service.

Why it matters to the business

Web applications using Rack for file uploads or multipart forms can experience prolonged response times or complete unavailability, leading to service disruption for Rails-based sites and increased operational costs during sustained attacks.

How an attack unfolds

An attacker sends a single HTTP request containing a maliciously constructed Content-Disposition header to any endpoint that processes multipart form data. The Rack parser enters a slow path that consumes CPU resources for an extended period, potentially exhausting server capacity when multiple such requests are issued.

How to fix it

Upgrade Rack to version 3.1.16 or later, which includes the fix committed in df2f3f2804373acafc429ed9f0770847a9c6b226. Applications should restart after the update and verify multipart handling continues to function.

How to confirm the fix worked

Confirm the installed Rack gem version is at least 3.1.16, test multipart form submissions with known benign inputs, and monitor request processing latency under load to ensure no regression to slow parsing behavior.

Typical attack path

1. Identify a target endpoint accepting multipart/form-data POST requests
2. Craft a Content-Disposition header value that induces excessive parsing time
3. Transmit the request repeatedly or in volume to amplify resource consumption
4. Observe service degradation or outage as CPU is exhausted

How to detect it

Examine web server and application logs for multipart requests with unusually long processing times or high CPU usage on Rack worker processes; correlate with request timestamps showing repeated submissions from the same sources.

What your security team should do

• Immediately upgrade all Rack installations to 3.1.16 or newer
• Review and prioritize patching of internet-facing Rails applications first
• Implement request rate limiting on multipart endpoints as a temporary control
• Add monitoring for unusually long request durations in application logs