CVE-2026-34230

What it actually does

This vulnerability is an algorithmic denial-of-service issue in Rack's handling of the HTTP Accept-Encoding header. In affected Rack versions before 2.2.23, 3.1.21, and 3.2.6, Rack::Utils.select_best_encoding can take quadratic time when parsing headers containing many wildcard (*) encoding entries. Applications that use Rack::Deflater are exposed because the middleware invokes this logic to decide whether and how to compress responses. A remote unauthenticated attacker can trigger excessive CPU consumption with crafted HTTP requests, reducing availability without needing authentication, user interaction, or code execution.

Why it matters to the business

Public-facing Ruby web applications using affected Rack versions with Rack::Deflater may become slow or unavailable under low-volume malicious traffic. Because exploitation requires only network access and a crafted request header, the issue can affect customer-facing portals, APIs, and internal web services exposed to untrusted clients. The CVSS score indicates limited availability impact, EPSS is currently low, it is not listed in CISA KEV, and no mature public exploitation is indicated, but the simplicity of the attack makes timely patching important for internet-exposed services.

How an attack unfolds

An attacker identifies a Ruby web application or API that uses Rack with response compression enabled through Rack::Deflater. The attacker sends HTTP requests containing an Accept-Encoding header with a large number of wildcard (*) values. When the request reaches the Rack middleware stack, Rack::Deflater calls Rack::Utils.select_best_encoding to determine the preferred response encoding. In vulnerable versions, this selection logic performs inefficient comparisons against the repeated wildcard entries, causing CPU usage to grow disproportionately relative to the size of the request. Repeating these requests can tie up application worker CPU, increase latency, exhaust request-processing capacity, and produce a denial-of-service condition.

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. Rebuild and redeploy applications after updating dependencies, and ensure lockfiles such as Gemfile.lock are refreshed so the runtime actually uses the fixed Rack version. If immediate upgrade is not possible, mitigate by limiting or normalizing unusually long Accept-Encoding headers at a reverse proxy, load balancer, WAF, or ingress gateway; rejecting requests with excessive header length or excessive comma-separated encoding tokens; and temporarily disabling Rack::Deflater where operationally acceptable. Rate limiting by source IP and request concurrency limits can reduce impact but should not be treated as a complete fix.

How to confirm the fix worked

Confirm the deployed Rack package version is 2.2.23, 3.1.21, 3.2.6, or later depending on the branch in use. Validate dependency resolution with package tooling, for example by checking the resolved Rack version in Gemfile.lock or using bundle info rack in deployed artifacts. Confirm Rack::Deflater exposure by reviewing middleware configuration or running application middleware inspection in a safe environment. Test ingress controls by sending benign requests with unusually large Accept-Encoding headers and verifying they are rejected, normalized, or handled without abnormal CPU spikes. Monitor application CPU, request latency, and worker saturation during validation to ensure the patched behavior is effective.

Typical attack path

1. Identify a Rack-based Ruby web application or API reachable over the network.
2. Determine or assume that response compression middleware such as Rack::Deflater is enabled.
3. Send HTTP requests with an Accept-Encoding header containing many repeated wildcard (*) entries.
4. Trigger quadratic-time processing in Rack::Utils.select_best_encoding during response encoding selection.
5. Repeat or distribute the crafted requests to consume application worker CPU and degrade service availability.

How to detect it

Look for evidence of high-CPU denial-of-service activity correlated with HTTP requests containing unusually large or repetitive Accept-Encoding headers. Relevant log sources include reverse proxy logs, load balancer logs, WAF events, CDN request logs, application access logs, application performance monitoring traces, container or host CPU metrics, and process supervisor logs showing worker timeouts or restarts. Search for requests where Accept-Encoding contains many comma-separated wildcard (*) values, unusually long header values, or repeated encoding negotiation tokens. Correlate these requests with spikes in CPU usage by Ruby application processes, increased request latency, request queue buildup, 502/503/504 responses, worker timeouts, or autoscaling events. Because this vulnerability causes resource exhaustion rather than code execution, durable host artifacts are not expected; detection should focus on request patterns and availability telemetry.

• Accept-Encoding: *
• Accept-Encoding: *,*
• Accept-Encoding: *, *, *
• Accept-Encoding: *,*,*,*,*
• Rack::Deflater
• Rack::Utils.select_best_encoding
• HTTP_ACCEPT_ENCODING
• 503
• 504
• upstream timed out
• worker timeout
• request timeout
• SIGKILL
• PumaWorkerKiller
• puma: cluster worker
• unicorn worker timeout

What your security team should do

• Inventory Ruby applications and services that include Rack, especially internet-facing services and APIs.
• Prioritize remediation for applications using Rack::Deflater or other compression paths that process Accept-Encoding headers.
• Upgrade Rack to 2.2.23, 3.1.21, 3.2.6, or later and redeploy affected services.
• Add temporary WAF, reverse proxy, or load balancer controls to block excessive Accept-Encoding header length or repeated wildcard tokens until patching is complete.
• Review access logs for spikes in requests with abnormal Accept-Encoding headers and correlate with CPU saturation, elevated latency, 5xx responses, or worker restarts.
• Ensure dependency scanning and lockfile auditing detect vulnerable Rack versions across repositories, containers, and deployed artifacts.
• Tune monitoring alerts for application CPU exhaustion, request queue depth, and abnormal compression-related traffic patterns.