Rack hat eine Content-Length-Fehlübereinstimmung in Rack::Files-Fehlerantworten

The core issue lies in the Rack::Files#fail method using String#size instead of String#bytesize to determine the Content-Length header. When a request includes a non-existent path containing percent-encoded UTF-8 characters, the declared Content-Length becomes smaller than the actual number of bytes transmitted. This discrepancy can cause problems for clients that rely on the Content-Length header for accurate data consumption. While not a direct remote code execution vulnerability, it can lead to denial-of-service conditions or unexpected application behavior if clients misinterpret the response. The impact is primarily client-side, but widespread deployments of Rack could be affected.

Applications and services relying on the Ruby Rack library, particularly those that process user-supplied paths or handle internationalized content, are at risk. Shared hosting environments that bundle Rack with other software components are also potentially vulnerable, as are applications that heavily depend on accurate HTTP response framing for proper functionality.

• ruby / server:

 gem list rack

• ruby / server:

 grep -r 'String#size' /path/to/rack/lib/

• generic web:

 curl -I https://example.com/path%E2%82%AC

(Check Content-Length header against response body size) • generic web:

 grep 'Content-Length' /var/log/apache2/access.log

(Look for discrepancies between Content-Length and bytes transferred)

1. 2026-04-02Disclosure

   disclosure

1. Reserviert2026-03-30
2. Veröffentlicht2026-04-02
3. Geändert2026-04-06
4. EPSS aktualisiert2026-04-10

The primary mitigation is to upgrade to Rack version 2.2.23 or later, which corrects the Content-Length calculation. If upgrading is not immediately feasible, consider implementing a reverse proxy or WAF that can normalize HTTP responses and ensure accurate Content-Length headers. Carefully review application code that relies on the Content-Length header for data integrity and consider adding validation or error handling to gracefully handle potentially truncated responses. There are no specific Sigma or YARA rules applicable to this vulnerability as it's a header calculation issue.