CVE-2026-34763

What it actually does

Rack::Directory builds a regular expression using the configured filesystem root without escaping regex metacharacters. If the root path contains characters such as '+', '*', or '.', Rack may fail to strip the intended prefix when rendering a directory listing, causing the generated HTML page to disclose the absolute filesystem path of the served directory. The flaw is remotely reachable where Rack::Directory is enabled and directory listings are exposed, requires no authentication or user interaction, and impacts confidentiality only.

Why it matters to the business

An unauthenticated user may be able to learn internal filesystem paths from a Ruby/Rack-based web application. While this does not directly allow code execution or data modification, leaked paths can reveal deployment structure, usernames, application layout, mounted volumes, or technology details that make later attacks easier. The issue is not listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, so it is generally a moderate-priority hardening fix unless directory listing is internet-exposed or path secrecy is important for the application.

How an attack unfolds

An attacker first identifies a Rack application endpoint that uses Rack::Directory to serve browsable directory listings. They then request directory paths and inspect the returned HTML. If the application was configured with a root path containing regex metacharacters, Rack may incorrectly process the root-prefix removal logic and render the full underlying filesystem path instead of a relative display path. The attacker records those disclosed paths and uses them for reconnaissance, such as inferring deployment directories, usernames, container paths, application framework layout, or locations that may be useful when chaining with other vulnerabilities such as file disclosure, path traversal, misconfigured static file serving, or error-message leakage.

How to fix it

Upgrade Rack to a patched release: 2.2.23 or later for the 2.2.x branch, 3.1.21 or later for the 3.1.x branch, or 3.2.6 or later for the 3.2.x branch. If immediate upgrade is not possible, disable Rack::Directory for untrusted users, remove public directory browsing, place directory listings behind authentication, avoid configuring Rack::Directory roots with regex metacharacters, and use a reverse proxy or application-layer rule to block access to directory-listing endpoints. Treat mitigation as temporary because the safest fix is to use a patched Rack version that correctly escapes the root path before regex use.

How to confirm the fix worked

Confirm the installed Rack version is 2.2.23, 3.1.21, 3.2.6, or newer on the active application runtime, not only in source control. For Ruby applications, inspect dependency lockfiles such as Gemfile.lock and verify the deployed gem version with runtime package inventory or `bundle exec ruby -e 'require "rack"; puts Rack.release'`. Identify whether Rack::Directory is configured by reviewing Rack config, config.ru, middleware declarations, or routes serving directory listings. After upgrading, request affected directory-listing URLs and verify that returned HTML shows only intended relative paths and does not include absolute filesystem prefixes such as application root, home directories, container mount paths, or release directories.

Typical attack path

1. Discover a Ruby/Rack web application exposing Rack::Directory or browsable static directory listings.
2. Send unauthenticated HTTP GET requests to directory-listing endpoints.
3. Review the returned HTML for absolute filesystem paths instead of relative directory names.
4. Extract disclosed paths, deployment names, usernames, or application structure from the listing.
5. Use the leaked path information to support follow-on reconnaissance or chaining with other vulnerabilities.

How to detect it

To determine whether this was already exploited, review HTTP access logs for unauthenticated GET requests to endpoints that render Rack::Directory listings, especially high-volume browsing across many directories, requests from unfamiliar scanners, or requests returning HTTP 200 with unusually large HTML directory-index responses. Inspect application, reverse-proxy, CDN, and WAF logs for directory-enumeration patterns before and after the patch date. If response-body logging, web caches, CDN cache objects, or synthetic monitoring captures are available, search returned HTML for absolute filesystem paths such as `/app/`, `/srv/`, `/var/www/`, `/home/`, `/usr/local/`, release directories, or container mount paths appearing in directory-listing pages. Also review public search-engine caches, archived pages, and observability traces if they store response bodies. There are no unique payload strings for exploitation because exploitation can be a normal HTTP GET to a directory-listing URL; detection is therefore based on exposed Rack::Directory usage, path disclosures in responses, and suspicious enumeration behavior rather than a reliable exploit signature.

What your security team should do

• Inventory internet-facing Ruby/Rack applications and identify any use of Rack::Directory or public directory listings.
• Upgrade Rack to 2.2.23, 3.1.21, 3.2.6, or later according to the application’s supported branch.
• Prioritize externally exposed applications, applications with public static browsing enabled, and deployments whose root paths contain regex metacharacters such as '+', '*', or '.'.
• Disable directory browsing unless there is a clear business requirement for it.
• Review recent web responses or cached pages for accidental disclosure of absolute filesystem paths.
• Add regression tests that request directory-listing pages and assert that absolute filesystem paths are not rendered.
• Monitor web access logs for unusual enumeration of directory-listing endpoints, especially repeated GET requests across many directories.