CVE-2026-22860

What it actually does

Rack::Directory incorrectly validates requested filesystem paths by comparing the expanded requested path to the configured root using a simple string prefix check. If a sibling or otherwise adjacent path begins with the same byte sequence as the intended root path, a crafted request containing traversal such as `/../root_example/` can pass the check even though the resolved path is outside the configured directory. The primary impact is unauthorized disclosure through directory listing and file enumeration outside the intended web-exposed root. The vulnerability is remotely reachable, requires no authentication or user interaction, and has confidentiality impact but does not directly provide code execution, data modification, or service disruption.

Why it matters to the business

Applications that expose Rack::Directory may unintentionally reveal files and directory names outside the intended public directory. This can expose source code, configuration files, secrets, deployment artifacts, internal documentation, backups, or other sensitive files depending on filesystem layout and application permissions. Although EPSS is currently low and the issue is not listed in CISA KEV, it has been public for 172 days and is straightforward to test, so internet-facing Ruby services using vulnerable Rack versions should be remediated promptly, especially where directory browsing is enabled or static file roots sit near similarly named directories.

How an attack unfolds

An attacker first identifies a Ruby/Rack application or component that serves directory listings using Rack::Directory. They then infer or brute-force the configured directory root name from URLs, page titles, directory index output, common deployment paths, or error behavior. Because vulnerable Rack versions only check whether the expanded candidate path starts with the configured root string, the attacker requests a traversal path that resolves to a different directory whose absolute path still begins with the same string, such as moving from a configured root named `root` to a sibling named `root_example`. If the target directory is readable by the application process and Rack::Directory renders it, the attacker receives an index listing or files from outside the intended root. The attacker can then enumerate directories, download exposed files, and use disclosed information such as credentials, source code, or infrastructure details for follow-on attacks.

How to fix it

Upgrade Rack to a fixed release: 2.2.22 or later for the 2.2.x branch, 3.1.20 or later for the 3.1.x branch, or 3.2.5 or later for the 3.2.x branch. If consuming Rack directly from Git, include commit `0cc2e00b22dffc33955ef912569f01e515a406e1` or a later commit containing the fix. Update dependency lockfiles such as `Gemfile.lock`, rebuild application images, and redeploy all affected services. If immediate upgrade is not possible, disable Rack::Directory, remove public directory listing functionality, ensure web-exposed static roots do not have similarly prefixed sibling directories, restrict filesystem permissions so the application process cannot read sensitive adjacent directories, and block traversal patterns such as `/../`, `%2e%2e%2f`, and `%2e%2e/` at a reverse proxy or WAF as a temporary defense. Treat proxy/WAF filtering as mitigation only, not a substitute for upgrading.

How to confirm the fix worked

Confirm the deployed Rack version is 2.2.22, 3.1.20, 3.2.5, or newer by checking dependency manifests and runtime package inventory, for example `bundle info rack`, `bundle exec ruby -e 'require "rack"; puts Rack.release'`, `Gemfile.lock`, SBOMs, or container image package scans. Verify that applications no longer expose vulnerable Rack::Directory behavior by testing a non-production or authorized environment with a benign sibling-directory scenario and confirming traversal requests such as `/../root_example/` are rejected, normalized safely, or return 403/404 rather than a directory listing. Confirm reverse proxies, CDN caches, and application containers have all been redeployed and are not still running an older bundled Rack version. Also validate that directory listing is disabled unless explicitly required and that the application process cannot read sensitive files outside intended public directories.

Typical attack path

1. Identify a Rack-based Ruby application exposing directory browsing or static directory indexes.
2. Probe for Rack::Directory behavior by requesting paths that return generated directory listings, parent-directory links, or file index pages.
3. Craft traversal requests using `../` or URL-encoded equivalents that resolve outside the configured root while still matching the root path prefix string.
4. Target sibling paths with similar prefixes to the configured root, for example `/../root_example/` when the configured root path ends in `root`.
5. Review HTTP responses for directory indexes, file names, source files, configuration files, backup archives, or secret material.
6. Download exposed files and use any disclosed credentials, keys, application code, or infrastructure details for lateral movement or additional compromise.

How to detect it

To determine whether exploitation was attempted or successful, review HTTP access logs from web servers, reverse proxies, CDNs, WAFs, load balancers, and application logs for requests containing path traversal sequences directed at routes handled by Rack::Directory. Focus on requests with `../`, URL-encoded dot-dot sequences, double-encoded traversal, or paths resembling `/../<root-like-name>/`. Prioritize responses with HTTP 200, 206, or unusually large response bodies, as these may indicate successful file or directory disclosure; 301/302, 403, and 404 may still indicate probing. Look for Rack-generated directory index responses in application logs or captured HTTP telemetry, including HTML directory listings, parent-directory links, and file names outside expected static roots. Correlate suspicious requests with subsequent downloads of configuration files, source files, archives, hidden files, credentials, or keys. If file access auditing is enabled, look for the application process reading directories or files outside the intended public root at the same timestamps as suspicious web requests. No specific public threat actors or ransomware campaigns are currently associated with this issue in the provided data.

• /../root_example/
• ../root_example/
• %2e%2e%2froot_example%2f
• %2e%2e/root_example/
• ..%2froot_example%2f
• %252e%252e%252froot_example%252f
• GET /../
• GET /%2e%2e%2f
• GET /%2e%2e/
• GET /..%2f
• GET /%252e%252e%252f
• ../
• %2e%2e%2f
• ..%2f
• %252e%252e%252f
• Rack::Directory
• <title>Directory:
• <h1>Directory:
• Parent Directory

What your security team should do

• Inventory all Ruby applications, containers, gems, and vendored dependencies that include Rack, prioritizing internet-facing services and applications that serve directory indexes or static files through Rack::Directory.
• Upgrade affected Rack installations to 2.2.22, 3.1.20, 3.2.5, or later, and regenerate lockfiles and images to ensure the fixed dependency is actually deployed.
• Search application code and middleware configuration for `Rack::Directory` usage and disable it where directory listing is not a business requirement.
• Review filesystem layouts for public directories with similarly prefixed sibling directories, such as `root` and `root_example`, and remove sensitive readable content from adjacent paths.
• Add temporary WAF or reverse-proxy detections for traversal patterns while patching, but avoid relying on filtering as the permanent control.
• Review web access logs since public disclosure for traversal attempts, encoded dot-dot sequences, and successful 200 responses returning directory index content outside expected static paths.
• If suspicious access is found, investigate whether sensitive files were disclosed, rotate exposed credentials or keys, and review subsequent authentication and infrastructure logs for follow-on activity.