CVE-2026-34786: Rack : Static Header_rules Bypass Vulnerability

MODERATE
Advisory Identifier: GHSA-q4qf-9j86-f5mh
CVSS 5.3
CWE-180
Published
Advisory Summary

CVE-2026-34786 is a MODERATE (CVSS 5.3) : static header_rules bypass vulnerability (CWE-180: Incorrect Behavior Order: Validate Before Canonicalize) affecting Rack libraries in the RubyGems ecosystem. The issue involves : static header_rules bypass via url-encoded paths. Remediation is available by upgrading affected packages to version 2.2.23, 3.1.21, 3.2.6.

CVE-2026-34786 at a Glance

CVE Identifier CVE-2026-34786
GHSA Identifier GHSA-q4qf-9j86-f5mh
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-180: Incorrect Behavior Order: Validate Before Canonicalize
Affected Product Rack
Package Ecosystem RubyGems
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-34786

To remediate this vulnerability, upgrade all affected Rack dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

rack fixed: 2.2.23
Upgrade rack to 2.2.23
rack fixed: 3.1.21
Upgrade rack to 3.1.21
rack fixed: 3.2.6
Upgrade rack to 3.2.6
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for rack

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-34786, inspect your project dependencies for Rack:

inspect dependencies for rack

Analyze the terminal output to locate any version of Rack in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.2.23), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-180: Incorrect Behavior Order: Validate Before Canonicalize, where the product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step. In Rack, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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.

CVE-2026-34786 Affected Rack Versions

3 component(s)
Fixed Versions:
2.2.233.1.213.2.6
Product / Package Ecosystem Affected Versions Fixed Version
rack
RubyGems
< 2.2.23
2.2.23
rack
RubyGems
≥ 3.0.0.beta1
< 3.1.21
3.1.21
rack
RubyGems
≥ 3.2.0
< 3.2.6
3.2.6

References

Frequently Asked Questions

What is CVE-2026-34786?
CVE-2026-34786 is a security vulnerability in Rack involving : Static header_rules bypass via URL-encoded paths under CWE-180: Incorrect Behavior Order: Validate Before Canonicalize.
Which Rack versions are affected?
Affected versions include releases prior to 2.2.23, 3.1.21, 3.2.6 across affected packages: rack.
What version fixes CVE-2026-34786?
Upgrading to 2.2.23, 3.1.21, 3.2.6 (or the latest patched release for your respective branch) resolves the vulnerability.
Is rack affected?
Yes, rack is affected in releases prior to 2.2.23, 3.1.21, 3.2.6. Upgrade your dependency to 2.2.23, 3.1.21, 3.2.6 or later.
What is the CVSS score of CVE-2026-34786?
CVE-2026-34786 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N.
What CWE is associated with CVE-2026-34786?
CVE-2026-34786 is classified under CWE-180: Incorrect Behavior Order: Validate Before Canonicalize (The product validates input before it is canonicalized, which prevents the product from detecting data that becomes invalid after the canonicalization step.).
How can I check RubyGems dependencies for CVE-2026-34786?
Run the dependency tree command: 'inspect dependencies for rack'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-q4qf-9j86-f5mh",
  "modified" : "2026-05-13T15:20:50Z",
  "published" : "2026-04-02T18:44:49Z",
  "aliases" : [ "CVE-2026-34786" ],
  "summary" : "Rack:: Static header_rules bypass via URL-encoded paths",
  "details" : "## Summary\n\n`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.\n\nIn 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.\n\n## Details\n\n`Rack::Static#applicable_rules` matches rule types such as `:fonts`, `Array`, and `Regexp` directly against the incoming `PATH_INFO`. For example:\n\n```ruby\nwhen :fonts\n  /\\.(?:ttf|otf|eot|woff2|woff|svg)\\z/.match?(path)\nwhen Array\n  /\\.(#{rule.join('|')})\\z/.match?(path)\nwhen Regexp\n  rule.match?(path)\n```\n\nThese 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.\n\nFor example, both of the following requests may resolve to the same file on disk:\n\n```text\n/fonts/test.woff\n/fonts/test%2Ewoff\n```\n\nbut only the unencoded form may receive the headers configured through `header_rules`.\n\nThis creates a canonicalization mismatch between the path used for header policy decisions and the path ultimately used for file serving.\n\n## Impact\n\nApplications that rely on `Rack::Static` `header_rules` to apply security-relevant headers to static files may be affected.\n\nIn 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.\n\nThe 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.\n\n## Mitigation\n\n* Update to a patched version of Rack that applies `header_rules` to a decoded path consistently with static file resolution.\n* Do not rely solely on `Rack::Static` `header_rules` for security-critical headers where encoded path variants may reach the application.\n* Prefer setting security headers at the reverse proxy or web server layer so they apply consistently to both encoded and unencoded path forms.\n* Normalize or reject encoded path variants for static content at the edge, where feasible.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "RubyGems",
      "name" : "rack"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.2.23"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "RubyGems",
      "name" : "rack"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "3.0.0.beta1"
      }, {
        "fixed" : "3.1.21"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "RubyGems",
      "name" : "rack"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "3.2.0"
      }, {
        "fixed" : "3.2.6"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/rack/rack/security/advisories/GHSA-q4qf-9j86-f5mh"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-34786"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/rack/rack"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-34786.yml"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-180" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-02T18:44:49Z",
    "nvd_published_at" : "2026-04-02T17:16:25Z"
  }
}