CVE-2026-125110: Path Canonicalization Mismatch and Security Header Bypass in Rack::Static

Rack (rack) is the foundational modular web server interface for the Ruby ecosystem, providing a unified API connecting web servers and frameworks such as Ruby on Rails, Sinatra, and Hanami. Among its built-in middleware components is Rack::Static, which intercepts incoming HTTP requests for static assets (such as stylesheets, JavaScript files, images, and static HTML documents) and serves them directly from a configured root directory without invoking the downstream Ruby application.

In addition to basic file resolution, Rack::Static allows developers to define custom HTTP response headers through the :header_rules configuration option. This mechanism maps specific URL path prefixes, regular expressions, or file extensions to sets of HTTP headers. Security teams rely on :header_rules to enforce critical browser-side security policies—including Content-Security-Policy (CSP), X-Frame-Options, Content-Disposition, and Cache-Control—on sensitive directory trees or user-uploaded static assets.

CVE-2026-125110 (also tracked as GitHub Security Advisory GHSA-wvg4-6p58-3gh3) is a path canonicalization mismatch vulnerability classified under CWE-180 (Incorrect Behavior Order: Validate Before Canonicalize). When processing an incoming request, Rack::Static resolves the target file on the filesystem using a normalized path where dot-segments (.. and .) are collapsed. However, the middleware evaluates :header_rules against a path string that has only been percent-decoded, omitting the dot-segment normalization step.

Because of this discrepancy between the file retrieval path and the policy evaluation path, an unauthenticated remote attacker can construct requests containing dot-segments (for example, /public/../admin/restricted.html) that resolve to the target file while evading path-specific rule matchers. Consequently, the web server returns the requested static asset stripped of its protective HTTP response headers.

The root cause of CVE-2026-125110 lies in an inconsistent application of path canonicalization functions within lib/rack/static.rb. Rack provides two distinct utility methods in Rack::Utils for processing URL paths: Rack::Utils.unescape_path, which decodes percent-encoded octets (converting %2F to / and %2E to .), and Rack::Utils.clean_path_info, which canonicalizes path strings by resolving relative dot-segments (.. and .) and collapsing redundant directory separators.

When an HTTP request enters Rack::Static#call, the middleware checks whether the request targets a configured static route and then delegates physical file lookup and delivery to Rack::Files (formerly Rack::File). During this file resolution phase, the path is sanitized using both unescape_path and clean_path_info. This ensures that a request containing relative traversal sequences is safely collapsed to its canonical form within the designated static root before interacting with the underlying operating system filesystem.

Concurrently, Rack::Static invokes its internal helper method applicable_rules(path) to iterate through the @header_rules array and compile the HTTP headers to attach to the response. Prior to the patch, applicable_rules(path) executed ::Rack::Utils.unescape_path(path) on the incoming PATH_INFO string, but failed to wrap the result in ::Rack::Utils.clean_path_info.

This creates a classic time-of-check to time-of-use (TOCTOU) impedance mismatch between policy evaluation and resource access. When an attacker submits a path beginning with an benign prefix followed by a parent directory traversal—such as /css/../admin/secret.html or its percent-encoded equivalent /css/%2E%2E/admin/secret.html—applicable_rules evaluates the literal string /css/../admin/secret.html. Any rule checking if the path starts with /admin/ (via String prefix matching or anchored Regexp matching like /^\/admin\//) evaluates to false, while the file server collapses the path to /admin/secret.html and serves the restricted file.

In lib/rack/static.rb, Rack::Static supports several rule formats within the :header_rules configuration array: :all (matches every file), :fonts (matches common web font extensions), String (matches if the request path starts with the given string prefix), Regexp (matches if the regular expression matches the request path), and Array (matches file extensions).

In affected versions of Rack (< 2.2.25, >= 3.0, < 3.1.23, and >= 3.2, < 3.2.8), the applicable_rules method was implemented as follows:

# File: lib/rack/static.rb (Vulnerable Implementation)
# Convert HTTP header rules to HTTP headers
def applicable_rules(path)
  # FLAW: Only decodes percent-encoding; does not collapse '..' or '.' segments
  path = ::Rack::Utils.unescape_path(path)
 
  @header_rules.find_all do |rule, new_headers|
    case rule
    when :all
      true
    when :fonts
      /\.(?:ttf|otf|eot|woff2|woff)\z/.match?(path)
    when String
      # Prefix check fails if 'path' starts with '/css/../' instead of '/admin/'
      path.start_with?(rule)
    when Regexp
      rule.match?(path)
    when Array
      /\.(?:#{rule.join('|')})\z/.match?(path)
    else
      false
    end
  end
end

Because String rules rely on path.start_with?(rule) and Regexp rules frequently anchor against the leading directory path, any unnormalized dot-segment prepended to the path shifts the starting characters of path. Meanwhile, extension-based rules (:fonts and Array) match against the end of the string (\z) and remain largely unaffected unless dot-segments are appended to the end of the URI in a manner that still resolves on disk.

The official patch, committed across all maintained release branches (18a07fe553afb4d8a678d6a948cd6ba1e11e28be, 9d7f19484ffd5ed5e032678c26ee6eff96d3a0a3, and e88097ccb88be44d06d47b42daffe04929516ee4), resolves the issue by passing the unescaped path directly into ::Rack::Utils.clean_path_info before iterating over @header_rules:

File: lib/rack/static.rb
@@ -168,7 +168,7 @@ def call(env)
 
     # Convert HTTP header rules to HTTP headers
     def applicable_rules(path)
-      path = ::Rack::Utils.unescape_path(path)
+      path = ::Rack::Utils.clean_path_info(::Rack::Utils.unescape_path(path))
 
       @header_rules.find_all do |rule, new_headers|
         case rule

> [!NOTE] > Fix Completeness Assessment: The fix is complete and directly eliminates the canonicalization discrepancy within Rack::Static. By invoking ::Rack::Utils.clean_path_info(::Rack::Utils.unescape_path(path)), applicable_rules now executes the exact same transformation sequence in the exact same order as the underlying file server. Whether the attacker supplies raw dot-segments (..), percent-encoded dot-segments (%2e%2e), or percent-encoded slashes (%2f), unescape_path first converts all encoded characters into literal ASCII characters, and clean_path_info immediately collapses the resulting traversal sequences prior to rule evaluation.

Exploiting CVE-2026-125110 requires no authentication, special privileges, or complex timing. The sole prerequisite is that the target Ruby web application uses Rack::Static configured with path-specific :header_rules (specifically String prefix rules or path-sensitive Regexp rules) to apply security or caching headers to specific static directories.

Consider a Rack application configured with the following middleware options, as demonstrated in the upstream regression test suite (test/spec_static.rb):

opts = {
  urls: ["/css", "/admin"],
  root: dir,
  header_rules: [
    [:all, { 'cache-control' => 'public, max-age=100' }],
    ['/admin/', {
      'cache-control' => 'private, no-store',
      'x-frame-options' => 'DENY'
    }]
  ]
}

In this configuration, any file served under /admin/ is intended to override the global public, max-age=100 cache directive with private, no-store and append x-frame-options: DENY to prevent framing. Note that when urls: ["/css", "/admin"] is configured, Rack::Static#can_serve checks if the incoming path begins with any prefix in urls. By starting the request path with /css, the attacker satisfies the outer middleware routing check (can_serve), ensuring Rack::Static intercepts the request.

An attacker can bypass the /admin/ rule using four distinct payload variations tested in the official regression suite:

1. Standard Unencoded Dot-Segments:

   GET /css/../admin/secret.html HTTP/1.1
   Host: target-rack-app.local

   Note: Because some HTTP clients, browsers, or upstream reverse proxies automatically collapse unencoded /../ sequences before transmitting the request over the wire, attackers operating through standard web browsers or behind normalizing proxies will typically use percent-encoded variants.

2. Percent-Encoded Dot-Segments:

   GET /css/%2E%2E/admin/secret.html HTTP/1.1
   Host: target-rack-app.local

3. Fully Percent-Encoded Path Segments:

   GET /css%2F..%2Fadmin%2Fsecret.html HTTP/1.1
   Host: target-rack-app.local

4. Mixed Encoded Path Segments:

   GET /foo/..%2Fadmin/secret.html HTTP/1.1
   Host: target-rack-app.local

When the unpatched server processes any of these four requests, it returns HTTP status 200 OK with the body of /admin/secret.html. However, because only the :all rule matched during applicable_rules, the response headers contain cache-control: public, max-age=100 and completely omit x-frame-options: DENY.

CVE-2026-125110 is rated with a CVSS v3.1 base score of 5.3 (Medium) via the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. The vulnerability does not grant arbitrary directory traversal outside the configured Rack::Static root directory (Confidentiality Impact: None), as Rack::Files still restricts file reads to the designated static root. Instead, the impact is centered on the bypass of HTTP response header integrity controls (Integrity Impact: Low).

The concrete security consequences depend directly on which headers an application relies upon Rack::Static to enforce:

• Web Cache Deception and Cache Poisoning: If an application serves sensitive static exports, reports, or administrative views using a global public caching rule (Cache-Control: public, max-age=...) while overriding specific directories with Cache-Control: private, no-store, an attacker can request the sensitive asset via a dot-segment URL. Intermediate CDNs, reverse proxies, or shared caches will observe the fallback public directive and cache the confidential document, making it accessible to unauthorized users.
• Clickjacking (UI Redressing): Static HTML pages (such as embedded administrative tools or confirmation forms) protected against framing via path-specific X-Frame-Options: DENY or Content-Security-Policy: frame-ancestors 'none' rules can be loaded inside an attacker-controlled <iframe> by referencing the dot-segment URL.
• Cross-Site Scripting (XSS) and Content Injection: Applications that host user-uploaded static files (such as HTML, SVG, or XML documents) within a dedicated directory often mitigate script execution by applying a restrictive Content-Security-Policy (e.g., sandbox or default-src 'none') or X-Content-Type-Options: nosniff to the upload path. Bypassing these rules allows an attacker to upload a malicious SVG or HTML file and direct a victim to the dot-segment URL, executing arbitrary JavaScript in the context of the application's origin.
• Forced Download Bypass: If a path rule applies Content-Disposition: attachment to prevent the browser from rendering potentially dangerous file types inline, bypassing the rule causes the browser to render the content directly inside the viewport.

According to FIRST EPSS metrics, CVE-2026-125110 currently holds an EPSS score of 0.00251 (0.25% probability of exploitation within 30 days, placing it in the 16.56th percentile), and is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

The primary remediation is to upgrade the rack gem to a patched release that normalizes paths within Rack::Static#applicable_rules. The Rack maintenance team has released fixed versions across all supported branches:

• Rack 2.2 Series: Upgrade to 2.2.25 or later.
• Rack 3.0 / 3.1 Series: Upgrade to 3.1.23 or later.
• Rack 3.2 Series: Upgrade to 3.2.8 or later.

Developers can update their application dependencies using Bundler:

bundle update rack

After updating, verify the installed version inside Gemfile.lock and restart all application server processes (such as Puma, Unicorn, or Passenger).

> [!NOTE] > If an immediate gem upgrade is not operationally feasible, security teams can implement compensating controls at the reverse proxy layer or within the application's middleware stack.

1. Enforce Path Normalization and Header Policies at the Reverse Proxy: In production deployments, static asset delivery and security header assignment should ideally be offloaded to an upstream web server or reverse proxy (such as NGINX, Apache HTTP Server, or Envoy) or a Content Delivery Network (CDN). Ensure the upstream proxy is configured to normalize incoming request URIs and reject or collapse encoded dot-segments (%2e%2e) before evaluating location blocks or forwarding requests to the Rack backend.
2. Use Global or Extension-Based Rules in Rack::Static: If Rack::Static must be used in an unpatched environment, avoid relying on path-prefix String or anchored Regexp rules to apply restrictive security headers. Instead, apply restrictive headers globally using :all (e.g., setting X-Frame-Options: DENY and Cache-Control: private, no-store as the default for :all), and only use path-specific rules to relax policies for explicitly safe public directories like /css/ or /assets/.
3. Relocate Sensitive Assets Out of Public Static Roots: Confidential HTML files, administrative assets, or untrusted user uploads should not reside in directories served directly by Rack::Static. Move these files outside the public document root and serve them through authenticated application controllers where authorization and response headers are enforced programmatically.