CVE-2026-34831

What it actually does

Rack::Files generated 404 responses whose Content-Length header was calculated with Ruby String#size rather than String#bytesize. For paths containing multibyte UTF-8 characters, the character count can be smaller than the byte count actually transmitted. Because Rack reflects the requested path in the 404 body, a remote unauthenticated requester can create an HTTP response where the declared body length is shorter than the bytes sent. In susceptible proxy, cache, client, or keep-alive connection configurations that trust the incorrect Content-Length, this can cause HTTP response desynchronization and may enable limited response confusion, cache poisoning, or cross-response data integrity issues.

Why it matters to the business

Applications using vulnerable Rack versions may produce malformed HTTP responses when handling specially crafted missing-file requests. The likely operational impact is limited but can include confusing downstream proxies, caches, browsers, or API clients, potentially causing users or systems to receive mixed or misleading response content. The CVSS score is moderate-low, EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so this should be treated as a routine but important dependency update rather than an emergency response item. Because Rack is a foundational Ruby web component used across many Ruby applications and frameworks, affected versions may be present indirectly through application dependency chains.

How an attack unfolds

An attacker identifies a Rack-based application serving static files through Rack::Files or a framework path that uses Rack::Files behavior. The attacker sends an HTTP request for a non-existent resource whose path contains percent-encoded multibyte UTF-8 characters. Rack decodes or reflects that path into the 404 response body. The vulnerable code sets Content-Length based on the number of characters rather than the number of bytes, so the response header underreports the actual body length. If the same TCP connection is reused and an intermediary or client relies on the incorrect Content-Length, trailing bytes from the 404 response can be interpreted as part of a subsequent response, creating response desynchronization. Practical exploitation generally requires a favorable deployment topology, persistent connections, and downstream components that mishandle the malformed framing.

How to fix it

Upgrade Rack to a patched release: 2.2.23 or later for the 2.2.x line, 3.1.21 or later for the 3.1.x line, or 3.2.6 or later for the 3.2.x line. Update direct and transitive dependencies through the applicable Ruby dependency manager, rebuild application artifacts, and redeploy all services that bundle Rack. If immediate upgrade is not possible, reduce exposure by preventing Rack::Files from reflecting arbitrary request paths where feasible, normalizing or rejecting invalid and unusual percent-encoded UTF-8 in static-file paths, disabling unnecessary static-file serving in application processes, and placing conservative request normalization controls at the edge. Mitigations should not be considered equivalent to patching because the root issue is incorrect response length calculation.

How to confirm the fix worked

Confirm the deployed Rack version at runtime and in dependency lockfiles. For Bundler-based applications, review Gemfile.lock and verify that the rack gem resolves to 2.2.23 or later, 3.1.21 or later, or 3.2.6 or later. Rebuild containers or packages to ensure the patched gem is actually present in the running artifact, not only in source control. Functional validation can include sending a request for a non-existent path containing percent-encoded multibyte UTF-8 characters and verifying that the HTTP response Content-Length equals the actual byte length of the response body. Also verify that reverse proxies, caches, and load balancers no longer observe malformed or truncated response framing from patched application instances.

Typical attack path

1. Find a Ruby web application or service using a vulnerable Rack version prior to 2.2.23, 3.1.21, or 3.2.6.
2. Identify paths served by Rack::Files or static-file middleware that return Rack-generated 404 responses.
3. Send requests for non-existent paths containing percent-encoded multibyte UTF-8 characters.
4. Cause Rack to reflect the crafted path in the 404 response body while setting an incorrect Content-Length header.
5. Attempt to abuse keep-alive connections, reverse proxies, shared caches, or clients that trust the incorrect Content-Length.
6. Use response desynchronization effects to induce limited response confusion, cache corruption, or misassociation of response bytes.

How to detect it

To assess prior exploitation or probing, review HTTP access logs, reverse proxy logs, CDN logs, WAF logs, and application logs for requests to non-existent paths that include percent-encoded UTF-8 byte sequences and resulted in 404 responses. Focus on repeated requests using encoded non-ASCII characters, especially sequences beginning with %C2 through %F4, over persistent HTTP connections. Correlate suspicious requests with downstream anomalies such as proxy parse errors, cache warnings, client disconnects, connection resets, unexpected 5xx responses, HTTP protocol errors, or messages about invalid response framing or Content-Length mismatch. Because exploitation effects are topology-dependent and may not leave a unique application artifact, detection should combine request-pattern hunting with infrastructure log correlation around the same timestamps and source IPs. There are no known named threat actors, ransomware campaigns, or public exploit indicators associated with this issue based on the provided data.

• %C2
• %C3
• %C4
• %C5
• %C6
• %C7
• %C8
• %C9
• %CA
• %CB
• %CC
• %CD
• %CE
• %CF
• %D0
• %D1
• %D2
• %D3
• %D4
• %D5
• %D6
• %D7
• %D8
• %D9
• %DA
• %DB
• %DC
• %DD
• %DE
• %DF
• %E0
• %E1
• %E2
• %E3
• %E4
• %E5
• %E6
• %E7
• %E8
• %E9
• %EA
• %EB
• %EC
• %ED
• %EE
• %EF
• %F0
• %F1
• %F2
• %F3
• %F4
• Rack::Files
• Content-Length
• 404

What your security team should do

• Inventory Ruby applications and services that include the rack gem, including transitive framework dependencies.
• Prioritize upgrades for internet-facing applications, applications behind shared reverse proxies or caches, and services that use Rack::Files or serve static content through Rack.
• Upgrade to Rack 2.2.23, 3.1.21, 3.2.6, or a later compatible version, then redeploy all affected runtime artifacts.
• Search web access logs for crafted 404 requests containing percent-encoded multibyte UTF-8 sequences, especially repeated probing against non-existent paths.
• Review proxy, CDN, cache, and application gateway logs for HTTP framing anomalies, invalid Content-Length handling, connection resets, or response parsing errors near suspicious requests.
• Add dependency scanning rules or software composition analysis policies to flag vulnerable Rack versions in build pipelines.
• If patching is delayed, apply edge filtering for unusual percent-encoded UTF-8 in static-file paths and monitor for desynchronization indicators.