Summary
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.
Details
Rack::Files#fail constructs error responses using logic equivalent to:
def fail(status, body, headers = {})
body += "\n"
[
status,
{
"content-type" => "text/plain",
"content-length" => body.size.to_s,
"x-cascade" => "pass"
}.merge!(headers),
[body]
]
end
Here, body.size returns the number of characters, not the number of bytes. For multibyte UTF-8 strings, this produces an incorrect Content-Length value.
Rack::Files includes the decoded request path in 404 responses. A request containing percent-encoded UTF-8 path components therefore causes the response body to contain multibyte characters, while the Content-Length header still reflects character count rather than byte count.
As a result, the server can send more bytes than declared in the response headers.
This violates HTTP message framing requirements, which define Content-Length as the number of octets in the message body.
Mitigation
- Update to a patched version of Rack that computes
Content-LengthusingString#bytesize. - Avoid exposing
Rack::Filesdirectly to untrusted traffic until a fix is available, if operationally feasible. - Where possible, place Rack behind a proxy or server that normalizes or rejects malformed backend responses.
- Prefer closing backend connections on error paths if response framing anomalies are a concern.
Impact
Applications using Rack::Files may emit incorrectly framed error responses when handling requests for non-existent paths containing multibyte characters.
In some deployment topologies, particularly with keep-alive connections and intermediaries that rely on Content-Length, this mismatch may lead to response parsing inconsistencies or response desynchronization. The practical exploitability depends on the behavior of downstream proxies, clients, and connection reuse.
Even where no secondary exploitation is possible, the response is malformed and may trigger protocol errors in strict components.
CVE-2026-34831 has a CVSS score of 4.8 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.2.23, 3.1.21, 3.2.6); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
rack to 2.2.23 or later; rack to 3.1.21 or later; rack to 3.2.6 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-34831? CVE-2026-34831 is a medium-severity security vulnerability in rack (rubygems), affecting versions < 2.2.23. It is fixed in 2.2.23, 3.1.21, 3.2.6.
- How severe is CVE-2026-34831? CVE-2026-34831 has a CVSS score of 4.8 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of rack are affected by CVE-2026-34831? rack (rubygems) versions < 2.2.23 is affected.
- Is there a fix for CVE-2026-34831? Yes. CVE-2026-34831 is fixed in 2.2.23, 3.1.21, 3.2.6. Upgrade to this version or later.
- Is CVE-2026-34831 exploitable, and should I be worried? Whether CVE-2026-34831 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-34831 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-34831?
- Upgrade
rackto 2.2.23 or later - Upgrade
rackto 3.1.21 or later - Upgrade
rackto 3.2.6 or later
- Upgrade