CVE-2026-34831

Published Apr 2, 2026

Last updated a month ago

CVSS medium 4.8

Overview

Description
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Files#fail sets the Content-Length response header using String#size instead of String#bytesize. When the response body contains multibyte UTF-8 characters, the declared Content-Length is smaller than the number of bytes actually sent on the wire. Because Rack::Files reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters. This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect Content-Length value. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6.
Source
security-advisories@github.com
NVD status
Analyzed
Products
rack

Risk scores

CVSS 3.1

Type
Primary
Base score
6.5
Impact score
2.5
Exploitability score
3.9
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Severity
MEDIUM

Weaknesses

security-advisories@github.com
CWE-130

Social media

Hype score
Not currently trending

Configurations

Related CVEs

  1. Rack is a modular Ruby web server interface. From versions 3.0.0.beta1 to before 3.1.21, and 3.2.0 to before 3.2.6, Rack::Request parses the Host header using an AUTHORITY regular expression that accepts characters not permitted in RFC-compliant hostnames, including /, ?, #, and @. Because req.host returns the full parsed value, applications that validate hosts using naive prefix or suffix checks can be bypassed. This can lead to host header poisoning in applications that use req.host, req.url, or req.base_url for link generation, redirects, or origin validation. This issue has been patched in versions 3.1.21 and 3.2.6.•CVE-2026-34835
  2. Rack is a modular Ruby web server interface. From versions 3.0.0.beta1 to before 3.1.21, and 3.2.0 to before 3.2.6, Rack::Multipart::Parser#handle_mime_head parses quoted multipart parameters such as Content-Disposition: form-data; name="..." using repeated String#index searches combined with String#slice! prefix deletion. For escape-heavy quoted values, this causes super-linear processing. An unauthenticated attacker can send a crafted multipart/form-data request containing many parts with long backslash-escaped parameter values to trigger excessive CPU usage during multipart parsing. This results in a denial of service condition in Rack applications that accept multipart form data. This issue has been patched in versions 3.1.21 and 3.2.6.•CVE-2026-34827
  3. Rack is a modular Ruby web server interface. From versions 3.0.0.beta1 to before 3.1.21 and 3.2.0 to before 3.2.6, Rack::Utils.forwarded_values parses the RFC 7239 Forwarded header by splitting on semicolons before handling quoted-string values. Because quoted values may legally contain semicolons, a header can be interpreted by Rack as multiple Forwarded directives rather than as a single quoted for value. In deployments where an upstream proxy, WAF, or intermediary validates or preserves quoted Forwarded values differently, this discrepancy can allow an attacker to smuggle host, proto, for, or by parameters through a single header value. This issue has been patched in versions 3.1.21 and 3.2.6.•CVE-2026-32762
  4. Rack is a modular Ruby web server interface. From version 3.2.0 to before version 3.2.6, Rack::Multipart::Parser unfolds folded multipart part headers incorrectly. When a multipart header contains an obs-fold sequence, Rack preserves the embedded CRLF in parsed parameter values such as filename or name instead of removing the folded line break during unfolding. As a result, applications that later reuse those parsed values in HTTP response headers may be vulnerable to downstream header injection or response splitting. This issue has been patched in version 3.2.6.•CVE-2026-26962
  5. Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Sendfile#map_accel_path interpolates the value of the X-Accel-Mapping request header directly into a regular expression when rewriting file paths for X-Accel-Redirect. Because the header value is not escaped, an attacker who can supply X-Accel-Mapping to the backend can inject regex metacharacters and control the generated X-Accel-Redirect response header. In deployments using Rack::Sendfile with x-accel-redirect, this can allow an attacker to cause nginx to serve unintended files from configured internal locations. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6.•CVE-2026-34830

References

Sources include official advisories and independent security research.