CVE-2025-27610

What it actually does

This is a path traversal flaw in Rack::Static, the Rack middleware commonly used by Ruby web applications to serve static files. In affected Rack versions before 2.2.13, 3.0.14, and 3.1.12, encoded traversal sequences in user-supplied request paths are not validated correctly. As a result, an attacker can bypass the intended urls: restriction and cause Rack::Static to serve other files located under the configured root: directory. The practical impact depends on how root: is configured: if it points only to a public static directory, exposure may be limited; if it points to an application root or broad filesystem location, sensitive application files, configuration files, dependency manifests, or secrets may be exposed.

Why it matters to the business

Successful exploitation can lead to unauthorized disclosure of files that were never intended to be publicly accessible. Exposed configuration files may reveal credentials, secret keys, service endpoints, deployment details, or application internals that enable follow-on attacks. The risk is most significant for Ruby applications that use Rack::Static with root: set to an application directory or any directory containing non-public files. The issue is not currently listed in CISA KEV, has low EPSS, and no public exploit maturity is indicated, but it has been public for a long time and is straightforward to test remotely when the vulnerable middleware is exposed.

How an attack unfolds

An attacker first identifies a Ruby/Rack-based web application serving static content through Rack::Static. They then probe static URL paths with encoded path traversal sequences that may be decoded by Rack in a way that bypasses the configured urls: allowlist or prefix restriction. If the application is vulnerable and the requested target file exists under the configured root: directory, Rack::Static returns that file in the HTTP response. The attacker repeats this process using guessed filenames common to Ruby applications, such as dependency files, Rack configuration, environment files, or framework configuration files. Any disclosed secrets or operational details can then be used for credential theft, source code reconnaissance, cloud/service access attempts, or more targeted application exploitation.

How to fix it

Upgrade Rack to a fixed release: 2.2.13 or later for the 2.2 branch, 3.0.14 or later for the 3.0 branch, or 3.1.12 or later for the 3.1 branch. For source-based consumers, ensure the fix including commit df6c47357f6c6bec2d585f45f417285d813d9b3a is present. Rebuild and redeploy all affected applications and container images that package vulnerable Rack versions. If immediate upgrade is not possible, remove Rack::Static usage where feasible, serve static content through a dedicated web server/CDN/object storage layer, or ensure Rack::Static root: points only to a directory containing files that are intentionally public. Do not configure root: to the application root, repository root, home directory, or any directory containing secrets or configuration files. Add WAF or reverse-proxy rules to block encoded traversal patterns as a compensating control, but do not treat filtering as a substitute for upgrading.

How to confirm the fix worked

Confirm the installed Rack version in dependency manifests and runtime artifacts, such as Gemfile.lock, gem inventory, container SBOMs, and deployed application images. Validate that Rack resolves to 2.2.13, 3.0.14, 3.1.12, or a later fixed version. Review application configuration for Rack::Static usage and verify that root: points only to a deliberately public static-file directory. After patching or reconfiguration, send safe negative tests for encoded traversal attempts against static URL paths and confirm the application returns 403, 404, or equivalent denial responses rather than file contents. Also verify that sensitive files such as application config, dependency manifests, and environment files are not reachable through any static URL route.

Typical attack path

1. Identify a Rack or Ruby web application that serves static files directly through Rack::Static.
2. Enumerate likely static URL prefixes and observe response behavior for normal static assets.
3. Send requests containing URL-encoded path traversal sequences such as encoded ../ components.
4. Attempt to retrieve predictable files under the configured Rack::Static root directory.
5. Review successful HTTP 200/206 responses for sensitive configuration, credentials, secrets, or application internals.
6. Use any disclosed information to support follow-on attacks such as credential abuse, source-code-informed exploitation, or lateral movement into connected services.

How to detect it

Review historical web server, reverse proxy, CDN, WAF, load balancer, and application access logs for requests to static routes containing encoded traversal sequences. Pay particular attention to requests with %2e, %2f, %5c, double-encoded traversal strings, or unusual attempts to access Ruby application files. Successful exploitation is most likely indicated by HTTP 200, 206, or unusually large 304 responses for filenames that should not be public, such as Gemfile, Gemfile.lock, config.ru, .env, config/database.yml, config/secrets.yml, config/master.key, or credentials files. Look for probing patterns where one source repeatedly requests many guessed filenames and receives a mix of 404 and successful responses. If EDR, file access auditing, or application instrumentation is available, correlate suspicious HTTP requests with the web application process reading sensitive files under the Rack::Static root directory. If any sensitive configuration or secret-bearing file was served, treat associated credentials and keys as potentially compromised.

• %2e%2e%2f
• %2e%2e/
• ..%2f
• %2e%2e%5c
• ..%5c
• %252e%252e%252f
• %252e%252e%255c
• /%2e%2e%2fGemfile
• /%2e%2e%2fGemfile.lock
• /%2e%2e%2fconfig.ru
• /%2e%2e%2f.env
• /%2e%2e%2fconfig%2fdatabase.yml
• /%2e%2e%2fconfig%2fsecrets.yml
• /%2e%2e%2fconfig%2fmaster.key
• /%2e%2e%2fconfig%2fcredentials.yml.enc
• /%252e%252e%252fGemfile
• /%252e%252e%252f.env
• GET /assets/%2e%2e%2f
• GET /static/%2e%2e%2f
• GET /public/%2e%2e%2f
• GET /packs/%2e%2e%2f

What your security team should do

• Inventory Ruby applications and services that depend on Rack and prioritize any internet-facing systems using Rack::Static.
• Upgrade Rack to 2.2.13, 3.0.14, 3.1.12, or later fixed versions, and rebuild/deploy affected images or packages.
• Search code and configuration for Rack::Static usage, especially configurations where root: is set to an application root or broad directory.
• Move static file serving to a CDN, reverse proxy, object storage bucket, or dedicated public directory where possible.
• Add temporary WAF/reverse-proxy detections and blocks for encoded path traversal sequences targeting static paths.
• Review historical access logs for traversal probes and successful responses serving sensitive Ruby or application configuration files.
• If sensitive files may have been exposed, rotate affected secrets and investigate downstream use of disclosed credentials.