Vulnerability GHSA-wvg4-6p58-3gh3

Medium Risk

10 hours ago

Rack: Rack::Static header_rules bypass via dot-segment normalization mismatch

0.1.0 - 0.4.0 and 0.9.0 - 1.1.0 and 1.1.1.pre and 1.1.1 - 1.2.8 and 1.3.0.beta and 1.3.0.beta2 and 1.3.0 - 1.4.7 and 1.5.0.beta.1 and 1.5.0.beta.2 and 1.5.0 - 1.5.5 and 1.6.0.beta and 1.6.0.beta2 and 1.6.0 - 1.6.13 and 2.0.0.alpha and 2.0.0.rc1 and 2.0.1 - 2.0.9 and 2.0.9.1 and 2.0.9.2 and 2.0.9.3 and 2.0.9.4 and 2.1.0 - 2.1.4 and 2.1.4.1 and 2.1.4.2 and 2.1.4.3 and 2.1.4.4 and 2.2.0 - 2.2.3 and 2.2.3.1 and 2.2.4 - 2.2.6 and 2.2.6.1 and 2.2.6.2 and 2.2.6.3 and 2.2.6.4 and 2.2.7 - 2.2.8 and 2.2.8.1 and 2.2.9 - 3.0.4 and 3.0.4.1 and 3.0.4.2 and 3.0.5 - 3.0.6 and 3.0.6.1 and 3.0.7 - 3.0.9 and 3.0.9.1 and 3.0.10 - 3.2.7

Summary

Rack: Rack::Static header_rules bypass via dot-segment normalization mismatch

Details

Summary

Rack::Static normalizes the request path with Utils.clean_path_info when deciding which file to serve, but matches header_rules against a path that is only URL-decoded. A request containing dot segments, raw or percent-encoded, is served the normalized target file while the header rules for that file's location are not applied.

This allows an attacker to receive a protected static file without the security headers configured for it.

Details

Rack::Static#call computes the served path as Utils.clean_path_info(Utils.unescape_path(path)). Rack::Static#applicable_rules applies only Utils.unescape_path before testing string and regular expression rules. A request for /assets/../uploads/file.html or /assets/..%2fuploads/file.html is served as uploads/file.html, but the decoded path /assets/../uploads/file.html does not start with uploads, so a rule scoped to that directory never matches.

The fix for CVE-2026-34786 (GHSA-q4qf-9j86-f5mh) added URL decoding to rule matching but did not add dot segment normalization, so versions that include that fix remain affected.

Impact

Applications that use Rack::Static header_rules to attach security-relevant headers to particular paths or file types are affected. An unauthenticated attacker who knows the path of a protected file can request it through a dot segment path and receive it without those headers, for example without Content-Disposition: attachment or a restrictive Content-Security-Policy that prevents uploaded HTML from rendering inline. The file itself is served unchanged. Applications that do not use path-specific header_rules are not affected.

Mitigation

Update to a patched version of Rack in which header_rules are matched against the same normalized path used to serve the file.
Reject requests containing dot segments at a reverse proxy or application boundary.
Do not rely solely on Rack::Static header_rules to prevent inline rendering of untrusted uploads; serve them from a separate origin.