GHSA/SYNC: 3 (of the 13) brand new rack advisories

Author: jasnow

gems/rack/CVE-2026-34785.yml

@@ -0,0 +1,87 @@
+---
+gem: rack
+cve: 2026-34785
+ghsa: h2jq-g4cq-5ppq
+url: https://github.com/rack/rack/security/advisories/GHSA-h2jq-g4cq-5ppq
+title: Rack::Static prefix matching can expose unintended files under
+  the static root
+date: 2026-04-02
+description: |
+  ## Summary
+
+  `Rack::Static` determines whether a request should be served as a
+  static file using a simple string prefix check. When configured
+  with URL prefixes such as `"/css"`, it matches any request path
+  that begins with that string, including unrelated paths such as
+  `"/css-config.env"` or `"/css-backup.sql"`.
+
+  As a result, files under the static root whose names merely share
+  the configured prefix may be served unintentionally, leading to
+  information disclosure.
+
+  ## Details
+
+  `Rack::Static#route_file` performs static-route matching using
+  logic equivalent to:
+
+  ```ruby
+  @urls.any? { |url| path.index(url) == 0 }
+  ```
+
+  This checks only whether the request path starts with the configured
+  prefix string. It does not require a path segment boundary after the prefix.
+
+  For example, with:
+
+  ```ruby
+  use Rack::Static, urls: ["/css", "/js"], root: "public"
+  ```
+
+  the following path is matched as intended:
+
+  ```text
+  /css/style.css
+  ```
+
+  but these paths are also matched:
+
+  ```text
+  /css-config.env
+  /css-backup.sql
+  /csssecrets.yml
+  ```
+
+  If such files exist under the configured static root, Rack forwards
+  the request to the file server and serves them as static content.
+
+  This means a configuration intended to expose only directory trees
+  such as `/css/...` and `/js/...` may also expose sibling files
+  whose names begin with those same strings.
+
+  ## Impact
+
+  An attacker can request files under the configured static root whose
+  names share a configured URL prefix and obtain their contents.
+
+  In affected deployments, this may expose configuration files,
+  secrets, backups, environment files, or other unintended static
+  content located under the same root directory.
+
+  ## Mitigation
+
+  * Update to a patched version of Rack that enforces a path boundary
+    when matching configured static URL prefixes.
+  * Match only paths that are either exactly equal to the configured
+    prefix or begin with `prefix + "/"`.
+  * Avoid placing sensitive files under the `Rack::Static` root directory.
+  * Prefer static URL mappings that cannot overlap with sensitive filenames.
+cvss_v3: 7.5
+patched_versions:
+  - "~> 2.2.23"
+  - "~> 3.1.21"
+  - ">= 3.2.6"
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2026-34785
+    - https://github.com/rack/rack/security/advisories/GHSA-h2jq-g4cq-5ppq
+    - https://github.com/advisories/GHSA-h2jq-g4cq-5ppq

gems/rack/CVE-2026-34786.yml

@@ -0,0 +1,90 @@
+---
+gem: rack
+cve: 2026-34786
+ghsa: q4qf-9j86-f5mh
+url: https://github.com/rack/rack/security/advisories/GHSA-q4qf-9j86-f5mh
+title: 'Rack:: Static header_rules bypass via URL-encoded paths'
+date: 2026-04-02
+description: |
+  ## Summary
+
+  `Rack::Static#applicable_rules` evaluates several `header_rules`
+  types against the raw URL-encoded `PATH_INFO`, while the underlying
+  file-serving path is decoded before the file is served. As a result,
+  a request for a URL-encoded variant of a static path can serve
+  the same file without the headers that `header_rules` were intended to apply.
+
+  In deployments that rely on `Rack::Static` to attach security-relevant
+  response headers to static content, this can allow an attacker to
+  bypass those headers by requesting an encoded form of the path.
+
+  ## Details
+
+  `Rack::Static#applicable_rules` matches rule types such as `:fonts`,
+  `Array`, and `Regexp` directly against the incoming `PATH_INFO`. For example:
+
+  ```ruby
+  when :fonts
+    /\.(?:ttf|otf|eot|woff2|woff|svg)\z/.match?(path)
+  when Array
+    /\.(#{rule.join('|')})\z/.match?(path)
+  when Regexp
+    rule.match?(path)
+  ```
+
+  These checks operate on the raw request path. If the request contains
+  encoded characters such as `%2E` in place of `.`, the rule may fail
+  to match even though the file path is later decoded and served
+  successfully by the static file server.
+
+  For example, both of the following requests may resolve to the
+  same file on disk:
+
+  ```text
+  /fonts/test.woff
+  /fonts/test%2Ewoff
+  ```
+
+  but only the unencoded form may receive the headers configured
+  through `header_rules`.
+
+  This creates a canonicalization mismatch between the path used
+  for header policy decisions and the path ultimately used for file serving.
+
+  ## Impact
+
+  Applications that rely on `Rack::Static` `header_rules` to apply
+  security-relevant headers to static files may be affected.
+
+  In affected deployments, an attacker can request an encoded
+  variant of a static file path and receive the same file without
+  the intended headers. Depending on how `header_rules` are used,
+  this may bypass protections such as clickjacking defenses, content
+  restrictions, or other response policies applied to static content.
+
+  The practical impact depends on the configured rules and the types
+  of files being served. If `header_rules` are only used for
+  non-security purposes such as caching, the issue may have limited
+  security significance.
+
+  ## Mitigation
+
+  * Update to a patched version of Rack that applies `header_rules`
+    to a decoded path consistently with static file resolution.
+  * Do not rely solely on `Rack::Static` `header_rules` for
+    security-critical headers where encoded path variants may
+    reach the application.
+  * Prefer setting security headers at the reverse proxy or web server
+    layer so they apply consistently to both encoded and unencoded path forms.
+  * Normalize or reject encoded path variants for static content
+    at the edge, where feasible.
+cvss_v3: 5.3
+patched_versions:
+  - "~> 2.2.23"
+  - "~> 3.1.21"
+  - ">= 3.2.6"
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2026-34786
+    - https://github.com/rack/rack/security/advisories/GHSA-q4qf-9j86-f5mh
+    - https://github.com/advisories/GHSA-q4qf-9j86-f5mh

gems/rack/CVE-2026-34826.yml

@@ -0,0 +1,78 @@
+---
+gem: rack
+cve: 2026-34826
+ghsa: x8cg-fq8g-mxfx
+url: https://github.com/rack/rack/security/advisories/GHSA-x8cg-fq8g-mxfx
+title: Rack's multipart byte range processing allows
+  denial of service via excessive overlapping ranges
+date: 2026-04-02
+description: |
+  ## Summary
+
+  `Rack::Utils.get_byte_ranges` parses the HTTP `Range` header without
+  limiting the number of individual byte ranges. Although the existing
+  fix for CVE-2024-26141 rejects ranges whose total byte coverage
+  exceeds the file size, it does not restrict the count of ranges.
+  An attacker can supply many small overlapping ranges such as
+  `0-0,0-0,0-0,...` to trigger disproportionate CPU, memory, I/O,
+  and bandwidth consumption per request.
+
+  This results in a denial of service condition in Rack file-serving
+  paths that process multipart byte range responses.
+
+  ## Details
+
+  `Rack::Utils.get_byte_ranges` accepts a comma-separated list of byte
+  ranges and validates them based on their aggregate size, but does
+  not impose a limit on how many individual ranges may be supplied.
+
+  As a result, a request such as:
+
+  ```http
+  Range: bytes=0-0,0-0,0-0,0-0,...
+  ```
+
+  can contain thousands of overlapping one-byte ranges while still
+  satisfying the total-size check added for CVE-2024-26141.
+
+  When such a header is processed by Rack’s file-serving code, each
+  range causes additional work, including multipart response generation,
+  per-range iteration, file seek and read operations, and temporary
+  string allocation for response size calculation and output. This
+  allows a relatively small request header to trigger disproportionately
+  expensive processing and a much larger multipart response.
+
+  The issue is distinct from CVE-2024-26141. That fix prevents range
+  sets whose total byte coverage exceeds the file size, but does not
+  prevent a large number of overlapping ranges whose summed size
+  remains within that limit.
+
+  ## Impact
+
+  Applications that expose file-serving paths with byte range support
+  may be vulnerable to denial of service.
+
+  An unauthenticated attacker can send crafted `Range` headers containing
+  many small overlapping ranges to consume excessive CPU time, memory,
+  file I/O, and bandwidth. Repeated requests may reduce application
+  availability and increase pressure on workers and garbage collection.
+
+  ## Mitigation
+
+  * Update to a patched version of Rack that limits the number
+    of accepted byte ranges.
+  * Reject or normalize multipart byte range requests containing
+    excessive range counts.
+  * Consider disabling multipart range support where it is not required.
+  * Apply request filtering or header restrictions at the reverse
+    proxy or application boundary to limit abusive `Range` headers.
+cvss_v3: 5.3
+patched_versions:
+  - "~> 2.2.23"
+  - "~> 3.1.21"
+  - ">= 3.2.6"
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2026-34826
+    - https://github.com/rack/rack/security/advisories/GHSA-x8cg-fq8g-mxfx
+    - https://github.com/advisories/GHSA-x8cg-fq8g-mxfx