CVE-2026-34829: Rack Multipart Parser DoS Vulnerability

CVE-2026-34829 Overview

A resource exhaustion vulnerability exists in Rack, the modular Ruby web server interface. The vulnerability is located in the Rack::Multipart::Parser component, which fails to properly limit the size of multipart file uploads when requests are sent without a Content-Length header. Prior to versions 2.2.23, 3.1.21, and 3.2.6, the parser only wraps the request body in a BoundedIO when CONTENT_LENGTH is present, allowing attackers to bypass size restrictions using HTTP chunked transfer encoding.

Critical Impact

Unauthenticated attackers can stream arbitrarily large multipart file uploads to exhaust disk space, causing denial of service conditions for Rack-based Ruby applications.

Affected Products

• Rack versions prior to 2.2.23
• Rack versions prior to 3.1.21
• Rack versions prior to 3.2.6

Discovery Timeline

• 2026-04-02 - CVE CVE-2026-34829 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-34829

Vulnerability Analysis

This vulnerability falls under the category of Resource Exhaustion (CWE-400). The issue stems from how Rack::Multipart::Parser handles multipart/form-data requests. Under normal operation, when a Content-Length header is provided, the parser wraps the incoming request body in a BoundedIO object that enforces size limits on the upload. However, this protection mechanism is conditional and only activates when the CONTENT_LENGTH environment variable is present.

When an attacker sends a multipart/form-data request using HTTP chunked transfer encoding (which does not require a Content-Length header), the BoundedIO wrapper is never applied. As a result, the multipart parsing continues until end-of-stream without any total size limit being enforced. For file parts specifically, the uploaded content is written directly to a temporary file on disk, bypassing the buffered in-memory upload limits that would normally constrain upload sizes.

Root Cause

The root cause is a missing boundary check in the Rack::Multipart::Parser component. The code conditionally applies the BoundedIO size-limiting wrapper only when the CONTENT_LENGTH header is present in the request. This creates an exploitable code path where chunked transfer encoding requests completely bypass the upload size validation logic, allowing unlimited data to be written to temporary files on the server's filesystem.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Crafting a multipart/form-data HTTP request
2. Using chunked transfer encoding instead of specifying a Content-Length header
3. Streaming an arbitrarily large file payload in the multipart body
4. The server writes the entire stream to a temporary file without size restrictions

This attack continues until the server's disk space is exhausted, causing denial of service for all applications relying on that storage. The vulnerability is particularly dangerous because it can be exploited by unauthenticated remote attackers against any Rack-based application that accepts multipart form data.

For detailed technical information, see the GitHub Security Advisory.

Detection Methods for CVE-2026-34829

Indicators of Compromise

• Unusual spikes in disk space consumption on application servers
• Large numbers of temporary files in the Rack temporary directory (typically /tmp or the configured temp path)
• HTTP requests with Transfer-Encoding: chunked combined with Content-Type: multipart/form-data
• Server processes consuming excessive I/O resources during multipart parsing

Detection Strategies

• Monitor disk space utilization on servers running Rack-based Ruby applications with alerting thresholds
• Implement request logging that captures Transfer-Encoding headers alongside multipart requests
• Deploy web application firewall (WAF) rules to detect and limit chunked transfer encoding requests to multipart endpoints
• Review application logs for failed requests due to disk space errors or I/O exceptions

Monitoring Recommendations

• Set up disk space monitoring with alerts at 80% and 90% thresholds on application servers
• Monitor temporary file creation rates in directories used by Rack for multipart processing
• Track network traffic for sustained large uploads using chunked encoding
• Implement application performance monitoring (APM) to detect unusual request processing times

How to Mitigate CVE-2026-34829

Immediate Actions Required

• Update Rack to version 2.2.23, 3.1.21, or 3.2.6 or later immediately
• Review and audit all Rack-based applications that accept multipart form data
• Consider implementing request size limits at the reverse proxy or load balancer level
• Monitor disk space utilization and set up automated alerts for unusual consumption patterns

Patch Information

The Rack development team has released patched versions that address this vulnerability. The fix ensures that size limits are properly enforced for multipart uploads regardless of whether a Content-Length header is present. Updated versions include:

• Rack 2.2.23 for the 2.x branch
• Rack 3.1.21 for the 3.1.x branch
• Rack 3.2.6 for the 3.2.x branch

For additional details, refer to the GitHub Security Advisory.

Workarounds

• Configure reverse proxies (nginx, Apache) to reject or limit chunked transfer encoding requests to multipart endpoints
• Implement disk quotas on temporary directories used by Rack applications
• Deploy rate limiting on endpoints that accept file uploads to reduce the impact of exploitation attempts
• Consider using a dedicated upload service with built-in size restrictions as an intermediate layer

# Example nginx configuration to limit request body size
# Add to server or location block for multipart endpoints
client_max_body_size 10m;
client_body_buffer_size 128k;
client_body_timeout 60s;