CVE-2026-34827

What it actually does

This vulnerability is an algorithmic-complexity denial-of-service issue in Rack multipart parsing. Affected Rack versions parse quoted multipart parameters in MIME part headers using repeated string searches and prefix deletion. When a multipart/form-data request contains many parts with long, escape-heavy quoted parameter values, parsing can become super-linear and consume excessive CPU. The attacker does not need authentication, user interaction, or application-specific privileges; any Rack-based application endpoint that accepts multipart form data, such as file upload or form submission routes, may be exposed. Confidentiality and integrity are not directly affected, but application availability can be significantly degraded.

Why it matters to the business

Successful exploitation can make Ruby web applications slow or unavailable by tying up application worker CPU during request parsing. This can disrupt customer-facing upload, form submission, API, or administrative workflows and may require emergency scaling, traffic filtering, or service restarts. Although the EPSS score is currently low and there is no known KEV or ransomware association, the flaw is network-reachable, unauthenticated, and easy to trigger against exposed multipart endpoints, so internet-facing Rack applications should be patched promptly.

How an attack unfolds

An attacker first identifies a Rack-based application endpoint that accepts multipart/form-data, such as a file upload, attachment, profile update, or form submission route. The attacker then sends HTTP POST requests with multipart bodies containing numerous parts whose Content-Disposition or similar multipart parameters include long quoted values with heavy use of backslash escaping. Before application code handles the request, Rack attempts to parse the multipart MIME headers. In vulnerable versions, the parser performs repeated String#index searches and String#slice! operations that become increasingly expensive as escaped quoted values grow. Repeating these requests can consume application worker CPU, slow request processing, exhaust available web workers, and cause a denial of service for legitimate users.

How to fix it

Upgrade Rack to a patched release: use Rack 3.1.21 or later for the 3.1.x line, or Rack 3.2.6 or later for the 3.2.x line. Applications using Rack versions from 3.0.0.beta1 through before 3.1.21, or 3.2.0 through before 3.2.6, should be treated as affected. If immediate upgrade is not possible, reduce exposure by enforcing strict request body size limits, multipart part-count limits, header length limits, upload endpoint rate limits, reverse-proxy request timeouts, and WAF or gateway rules that reject multipart requests with unusually long quoted parameters or excessive backslash escaping. Disable unused upload/form endpoints where feasible, and ensure application servers have bounded worker counts and sane request timeouts so a small number of malicious requests cannot monopolize capacity.

How to confirm the fix worked

Confirm the deployed Rack version in dependency manifests and runtime package inventories. For Bundler-based applications, check Gemfile.lock or equivalent dependency output and verify Rack is at least 3.1.21 or 3.2.6 depending on the release line. Confirm all application images, build artifacts, and deployed containers have been rebuilt with the patched dependency rather than only updating source manifests. Exercise legitimate multipart upload and form workflows after the upgrade to verify compatibility. From an exposure perspective, identify routes, reverse-proxy locations, or API endpoints that accept multipart/form-data and confirm request size, timeout, and rate-limit controls are active. Synthetic validation can include sending benign multipart requests with large quoted parameter values in a controlled test environment and confirming CPU does not spike abnormally after patching.

Typical attack path

1. Find a public or internal Rack application endpoint that accepts multipart/form-data requests.
2. Send crafted multipart/form-data POST requests containing many parts and long quoted multipart parameter values with dense backslash escaping.
3. Trigger expensive parsing inside Rack::Multipart::Parser before normal application request handling occurs.
4. Repeat or parallelize requests to keep Ruby application workers CPU-bound.
5. Cause elevated latency, request timeouts, worker exhaustion, or application unavailability.

How to detect it

Investigate for prior exploitation by correlating web access logs, reverse-proxy logs, WAF logs, application server logs, APM traces, and host CPU metrics. Look for bursts of POST requests using Content-Type: multipart/form-data to upload or form endpoints, especially requests with unusually large request headers or bodies, many multipart parts, long request durations, upstream timeout responses, 499/502/503/504 errors, or low response byte counts. Since exploitation occurs during request parsing, application business logs may show little or no route-level activity even while CPU spikes occur. In Ruby/Rack telemetry, look for time spent in Rack::Multipart::Parser or Rack::Multipart::Parser#handle_mime_head during high CPU intervals. WAF or packet captures may reveal Content-Disposition multipart headers containing quoted name or filename parameters with very long values and repeated backslash escape characters. Because this is a denial-of-service flaw rather than code execution, durable host artifacts are not expected; detection should focus on traffic shape, parser hot paths, CPU saturation, worker exhaustion, and timeout patterns.

• Content-Type: multipart/form-data
• Content-Disposition: form-data; name="
• Content-Disposition: form-data; filename="
• Rack::Multipart::Parser
• Rack::Multipart::Parser#handle_mime_head
• multipart/form-data; boundary=
• upstream timed out
• request timed out
• worker timeout
• HTTP 503
• HTTP 504
• POST

What your security team should do

• Prioritize patching internet-facing Rack applications that accept file uploads, attachments, or multipart form submissions.
• Upgrade Rack to 3.1.21 or later, or 3.2.6 or later, and rebuild/redeploy all affected application artifacts.
• Inventory Ruby applications and containers for Rack versions in the affected ranges, including transitive dependencies pulled in by frameworks.
• Add or verify reverse-proxy and application-layer limits for request body size, multipart part count, MIME header length, request duration, and upload rate.
• Create temporary WAF or gateway detection for multipart/form-data requests containing abnormally long quoted parameter values or repeated backslash escaping.
• Monitor application CPU, request latency, 4xx/5xx spikes, upstream timeout errors, and worker saturation around multipart endpoints.
• Review access logs for repeated POST requests to upload or form endpoints from the same source with large request bodies and failed or timed-out responses.
• Because there is no known KEV listing, ransomware association, or mature public exploit signal, treat this as high operational-risk hardening rather than an active mass-exploitation emergency unless local telemetry indicates abuse.