Skip to content

Commit 7642410

Browse files
jasnowRubySec CI
jasnow
authored and
RubySec CI
committed
Updated advisory posts against rubysec/ruby-advisory-db@a56864f 
1 parent edea7a9 commit 7642410

3 files changed

Lines changed: 278 additions & 0 deletions

File tree

‎advisories/_posts/2026-04-02-CVE-2026-34785.md‎

Lines changed: 95 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,95 @@
1+
---
2+
layout: advisory
3+
title: 'CVE-2026-34785 (rack): Rack::Static prefix matching can expose unintended
4+
files under the static root'
5+
comments: false
6+
categories:
7+
- rack
8+
advisory:
9+
gem: rack
10+
cve: 2026-34785
11+
ghsa: h2jq-g4cq-5ppq
12+
url: https://github.com/rack/rack/security/advisories/GHSA-h2jq-g4cq-5ppq
13+
title: Rack::Static prefix matching can expose unintended files under the static
14+
root
15+
date: 2026-04-02
16+
description: |
17+
## Summary
18+
19+
`Rack::Static` determines whether a request should be served as a
20+
static file using a simple string prefix check. When configured
21+
with URL prefixes such as `"/css"`, it matches any request path
22+
that begins with that string, including unrelated paths such as
23+
`"/css-config.env"` or `"/css-backup.sql"`.
24+
25+
As a result, files under the static root whose names merely share
26+
the configured prefix may be served unintentionally, leading to
27+
information disclosure.
28+
29+
## Details
30+
31+
`Rack::Static#route_file` performs static-route matching using
32+
logic equivalent to:
33+
34+
```ruby
35+
@urls.any? { |url| path.index(url) == 0 }
36+
```
37+
38+
This checks only whether the request path starts with the configured
39+
prefix string. It does not require a path segment boundary after the prefix.
40+
41+
For example, with:
42+
43+
```ruby
44+
use Rack::Static, urls: ["/css", "/js"], root: "public"
45+
```
46+
47+
the following path is matched as intended:
48+
49+
```text
50+
/css/style.css
51+
```
52+
53+
but these paths are also matched:
54+
55+
```text
56+
/css-config.env
57+
/css-backup.sql
58+
/csssecrets.yml
59+
```
60+
61+
If such files exist under the configured static root, Rack forwards
62+
the request to the file server and serves them as static content.
63+
64+
This means a configuration intended to expose only directory trees
65+
such as `/css/...` and `/js/...` may also expose sibling files
66+
whose names begin with those same strings.
67+
68+
## Impact
69+
70+
An attacker can request files under the configured static root whose
71+
names share a configured URL prefix and obtain their contents.
72+
73+
In affected deployments, this may expose configuration files,
74+
secrets, backups, environment files, or other unintended static
75+
content located under the same root directory.
76+
77+
## Mitigation
78+
79+
* Update to a patched version of Rack that enforces a path boundary
80+
when matching configured static URL prefixes.
81+
* Match only paths that are either exactly equal to the configured
82+
prefix or begin with `prefix + "/"`.
83+
* Avoid placing sensitive files under the `Rack::Static` root directory.
84+
* Prefer static URL mappings that cannot overlap with sensitive filenames.
85+
cvss_v3: 7.5
86+
patched_versions:
87+
- "~> 2.2.23"
88+
- "~> 3.1.21"
89+
- ">= 3.2.6"
90+
related:
91+
url:
92+
- https://nvd.nist.gov/vuln/detail/CVE-2026-34785
93+
- https://github.com/rack/rack/security/advisories/GHSA-h2jq-g4cq-5ppq
94+
- https://github.com/advisories/GHSA-h2jq-g4cq-5ppq
95+
---

‎advisories/_posts/2026-04-02-CVE-2026-34786.md‎

Lines changed: 97 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,97 @@
1+
---
2+
layout: advisory
3+
title: 'CVE-2026-34786 (rack): Rack:: Static header_rules bypass via URL-encoded paths'
4+
comments: false
5+
categories:
6+
- rack
7+
advisory:
8+
gem: rack
9+
cve: 2026-34786
10+
ghsa: q4qf-9j86-f5mh
11+
url: https://github.com/rack/rack/security/advisories/GHSA-q4qf-9j86-f5mh
12+
title: 'Rack:: Static header_rules bypass via URL-encoded paths'
13+
date: 2026-04-02
14+
description: |
15+
## Summary
16+
17+
`Rack::Static#applicable_rules` evaluates several `header_rules`
18+
types against the raw URL-encoded `PATH_INFO`, while the underlying
19+
file-serving path is decoded before the file is served. As a result,
20+
a request for a URL-encoded variant of a static path can serve
21+
the same file without the headers that `header_rules` were intended to apply.
22+
23+
In deployments that rely on `Rack::Static` to attach security-relevant
24+
response headers to static content, this can allow an attacker to
25+
bypass those headers by requesting an encoded form of the path.
26+
27+
## Details
28+
29+
`Rack::Static#applicable_rules` matches rule types such as `:fonts`,
30+
`Array`, and `Regexp` directly against the incoming `PATH_INFO`. For example:
31+
32+
```ruby
33+
when :fonts
34+
/\.(?:ttf|otf|eot|woff2|woff|svg)\z/.match?(path)
35+
when Array
36+
/\.(#{rule.join('|')})\z/.match?(path)
37+
when Regexp
38+
rule.match?(path)
39+
```
40+
41+
These checks operate on the raw request path. If the request contains
42+
encoded characters such as `%2E` in place of `.`, the rule may fail
43+
to match even though the file path is later decoded and served
44+
successfully by the static file server.
45+
46+
For example, both of the following requests may resolve to the
47+
same file on disk:
48+
49+
```text
50+
/fonts/test.woff
51+
/fonts/test%2Ewoff
52+
```
53+
54+
but only the unencoded form may receive the headers configured
55+
through `header_rules`.
56+
57+
This creates a canonicalization mismatch between the path used
58+
for header policy decisions and the path ultimately used for file serving.
59+
60+
## Impact
61+
62+
Applications that rely on `Rack::Static` `header_rules` to apply
63+
security-relevant headers to static files may be affected.
64+
65+
In affected deployments, an attacker can request an encoded
66+
variant of a static file path and receive the same file without
67+
the intended headers. Depending on how `header_rules` are used,
68+
this may bypass protections such as clickjacking defenses, content
69+
restrictions, or other response policies applied to static content.
70+
71+
The practical impact depends on the configured rules and the types
72+
of files being served. If `header_rules` are only used for
73+
non-security purposes such as caching, the issue may have limited
74+
security significance.
75+
76+
## Mitigation
77+
78+
* Update to a patched version of Rack that applies `header_rules`
79+
to a decoded path consistently with static file resolution.
80+
* Do not rely solely on `Rack::Static` `header_rules` for
81+
security-critical headers where encoded path variants may
82+
reach the application.
83+
* Prefer setting security headers at the reverse proxy or web server
84+
layer so they apply consistently to both encoded and unencoded path forms.
85+
* Normalize or reject encoded path variants for static content
86+
at the edge, where feasible.
87+
cvss_v3: 5.3
88+
patched_versions:
89+
- "~> 2.2.23"
90+
- "~> 3.1.21"
91+
- ">= 3.2.6"
92+
related:
93+
url:
94+
- https://nvd.nist.gov/vuln/detail/CVE-2026-34786
95+
- https://github.com/rack/rack/security/advisories/GHSA-q4qf-9j86-f5mh
96+
- https://github.com/advisories/GHSA-q4qf-9j86-f5mh
97+
---

‎advisories/_posts/2026-04-02-CVE-2026-34826.md‎

Lines changed: 86 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
1+
---
2+
layout: advisory
3+
title: 'CVE-2026-34826 (rack): Rack''s multipart byte range processing allows denial
4+
of service via excessive overlapping ranges'
5+
comments: false
6+
categories:
7+
- rack
8+
advisory:
9+
gem: rack
10+
cve: 2026-34826
11+
ghsa: x8cg-fq8g-mxfx
12+
url: https://github.com/rack/rack/security/advisories/GHSA-x8cg-fq8g-mxfx
13+
title: Rack's multipart byte range processing allows denial of service via excessive
14+
overlapping ranges
15+
date: 2026-04-02
16+
description: |
17+
## Summary
18+
19+
`Rack::Utils.get_byte_ranges` parses the HTTP `Range` header without
20+
limiting the number of individual byte ranges. Although the existing
21+
fix for CVE-2024-26141 rejects ranges whose total byte coverage
22+
exceeds the file size, it does not restrict the count of ranges.
23+
An attacker can supply many small overlapping ranges such as
24+
`0-0,0-0,0-0,...` to trigger disproportionate CPU, memory, I/O,
25+
and bandwidth consumption per request.
26+
27+
This results in a denial of service condition in Rack file-serving
28+
paths that process multipart byte range responses.
29+
30+
## Details
31+
32+
`Rack::Utils.get_byte_ranges` accepts a comma-separated list of byte
33+
ranges and validates them based on their aggregate size, but does
34+
not impose a limit on how many individual ranges may be supplied.
35+
36+
As a result, a request such as:
37+
38+
```http
39+
Range: bytes=0-0,0-0,0-0,0-0,...
40+
```
41+
42+
can contain thousands of overlapping one-byte ranges while still
43+
satisfying the total-size check added for CVE-2024-26141.
44+
45+
When such a header is processed by Rack’s file-serving code, each
46+
range causes additional work, including multipart response generation,
47+
per-range iteration, file seek and read operations, and temporary
48+
string allocation for response size calculation and output. This
49+
allows a relatively small request header to trigger disproportionately
50+
expensive processing and a much larger multipart response.
51+
52+
The issue is distinct from CVE-2024-26141. That fix prevents range
53+
sets whose total byte coverage exceeds the file size, but does not
54+
prevent a large number of overlapping ranges whose summed size
55+
remains within that limit.
56+
57+
## Impact
58+
59+
Applications that expose file-serving paths with byte range support
60+
may be vulnerable to denial of service.
61+
62+
An unauthenticated attacker can send crafted `Range` headers containing
63+
many small overlapping ranges to consume excessive CPU time, memory,
64+
file I/O, and bandwidth. Repeated requests may reduce application
65+
availability and increase pressure on workers and garbage collection.
66+
67+
## Mitigation
68+
69+
* Update to a patched version of Rack that limits the number
70+
of accepted byte ranges.
71+
* Reject or normalize multipart byte range requests containing
72+
excessive range counts.
73+
* Consider disabling multipart range support where it is not required.
74+
* Apply request filtering or header restrictions at the reverse
75+
proxy or application boundary to limit abusive `Range` headers.
76+
cvss_v3: 5.3
77+
patched_versions:
78+
- "~> 2.2.23"
79+
- "~> 3.1.21"
80+
- ">= 3.2.6"
81+
related:
82+
url:
83+
- https://nvd.nist.gov/vuln/detail/CVE-2026-34826
84+
- https://github.com/rack/rack/security/advisories/GHSA-x8cg-fq8g-mxfx
85+
- https://github.com/advisories/GHSA-x8cg-fq8g-mxfx
86+
---

0 commit comments

Comments
 (0)