CVE-2026-34829

What it actually does

CVE-2026-34829 is an unauthenticated network denial-of-service vulnerability in Rack multipart request parsing. Affected Rack versions only apply bounded request-body handling when the HTTP Content-Length header is present. If an attacker sends a multipart/form-data upload using chunked transfer encoding or otherwise omits Content-Length, Rack::Multipart::Parser continues reading until the connection ends without enforcing a total request-size limit. File parts are streamed directly to temporary files on disk, allowing an attacker to consume unbounded disk space and cause application errors or service outage. The issue affects Rack prior to 2.2.23, 3.1.21, and 3.2.6.

Why it matters to the business

Internet-facing Ruby applications that accept file uploads or multipart form submissions can be made unavailable by a remote unauthenticated attacker. The likely operational impact is exhausted disk space on application hosts or containers, failed uploads, failed request handling, crashes, degraded performance, and possible cascading failures if the same disk volume is shared by logs, databases, queues, or other services. Although there is no confidentiality or integrity impact, availability impact is high. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS at the provided score, but it is simple to trigger and should be prioritized for exposed upload endpoints.

How an attack unfolds

An attacker identifies a Rack-based Ruby application endpoint that accepts multipart/form-data, such as a file upload, form submission, API attachment endpoint, or any route that invokes multipart parsing. Instead of sending a normal request with a Content-Length header, the attacker sends the request using HTTP chunked transfer encoding or another method that omits Content-Length. Because vulnerable Rack versions do not wrap that body in the bounded I/O limiter, Rack continues to parse the multipart stream until the attacker closes the connection. The attacker then continuously streams a large file part. Rack writes the uploaded file part to a temporary file on disk, commonly under the system temporary directory, and disk usage grows until free space is exhausted or operational limits are hit. Once disk space is depleted, the application may return errors, fail to write logs or temporary files, crash workers, or become unavailable.

How to fix it

Upgrade Rack to a patched version: 2.2.23 or later on the 2.2.x branch, 3.1.21 or later on the 3.1.x branch, or 3.2.6 or later on the 3.2.x branch. Because Rack is often pulled in transitively by frameworks and middleware, update dependency lockfiles and rebuild/redeploy all affected applications, containers, and server images. If immediate upgrade is not possible, apply compensating controls: enforce maximum request body size at a reverse proxy, load balancer, ingress controller, WAF, or application server; reject multipart/form-data requests that omit Content-Length where feasible; limit or disable HTTP chunked uploads to upload endpoints where business requirements allow; enforce per-request, per-connection, and per-client rate limits; place temporary upload storage on a dedicated partition with quotas; and monitor disk utilization aggressively. Ensure upload endpoints enforce application-level file size limits in addition to infrastructure-level controls.

How to confirm the fix worked

Confirm the deployed Rack version is 2.2.23, 3.1.21, 3.2.6, or newer depending on the active branch. Validate through dependency manifests and runtime checks, such as Gemfile.lock, bundle info rack, gem list rack, container SBOMs, and deployed image package inventories. Confirm that all application instances, background web workers, and container images have been rebuilt and restarted after the dependency update. Test exposure safely in a non-production environment by sending a chunked multipart/form-data request without Content-Length that exceeds the configured upload limit and verify that it is rejected, terminated, or bounded before excessive disk growth occurs. Also verify reverse proxy or ingress limits by confirming oversized chunked multipart uploads receive an expected 4xx response and do not create large temporary files.

Typical attack path

1. Discover or guess a Rack-backed application endpoint that accepts multipart/form-data requests.
2. Open an HTTP connection to the endpoint without authentication if the endpoint is public or otherwise reachable.
3. Send a multipart/form-data request without a Content-Length header, commonly using Transfer-Encoding: chunked.
4. Include a file part in the multipart body and continuously stream data without ending the multipart request.
5. Cause Rack to write the streamed file part to a temporary file without an effective total-size bound.
6. Repeat or parallelize requests until the temporary filesystem or application disk volume is exhausted.
7. Trigger application errors, failed uploads, worker crashes, or broader service unavailability due to lack of disk space.

How to detect it

To determine whether exploitation has already occurred, review web server, reverse proxy, load balancer, WAF, and application logs for multipart/form-data requests that used Transfer-Encoding: chunked and lacked a Content-Length header, especially against upload or form submission endpoints. Look for long-lived requests, unusually large request bodies, client disconnects, repeated requests from the same source, abnormal 4xx/5xx responses, and sudden increases in request duration. Correlate these events with host and container telemetry showing rapid disk usage growth in temporary directories, application working directories, or upload staging paths. On Linux systems, review system logs and application logs for disk exhaustion errors such as Errno::ENOSPC, No space left on device, failed tempfile creation, failed log writes, worker crashes, or container eviction due to ephemeral storage exhaustion. Inspect temporary directories for large or numerous Rack multipart temporary files, commonly named with the RackMultipart prefix. If available, review process, file integrity, and EDR telemetry for Ruby application processes writing unusually large files under /tmp, /var/tmp, container ephemeral storage, or configured upload temp paths. Because this is a denial-of-service issue rather than code execution, expected artifacts are oversized temporary files, anomalous HTTP request patterns, and disk exhaustion events rather than malware-specific indicators.

• Transfer-Encoding: chunked
• Content-Type: multipart/form-data
• RackMultipart
• /tmp/RackMultipart
• /var/tmp/RackMultipart
• Errno::ENOSPC
• No space left on device
• failed to write tempfile
• Content-Length header missing
• multipart/form-data request without Content-Length
• client intended to send too large chunked body
• upstream prematurely closed connection

What your security team should do

• Inventory all Ruby/Rack applications, including applications using Rails, Sinatra, Hanami, Grape, or other Rack-based stacks, and identify deployed Rack versions.
• Prioritize internet-facing applications and any endpoint that accepts file uploads, attachments, multipart forms, or API multipart requests.
• Upgrade Rack to 2.2.23, 3.1.21, 3.2.6, or newer and redeploy all affected services.
• Add or verify request body size limits at the edge, including reverse proxies, load balancers, ingress controllers, WAFs, and application servers.
• Where compatible with business requirements, block or restrict chunked multipart uploads that omit Content-Length.
• Place upload temporary directories on dedicated storage with quotas to prevent one application from exhausting shared system disks.
• Create alerts for spikes in temporary file growth, disk utilization, HTTP 5xx errors, and repeated chunked multipart upload attempts.
• Review historical logs for suspicious multipart/form-data requests using Transfer-Encoding: chunked and no Content-Length, especially around upload routes.
• Exercise incident response procedures for disk-exhaustion denial of service, including safe cleanup of temporary upload files and controlled service restart.