CVE-2026-34785

What it actually does

Rack::Static uses an imprecise string-prefix comparison to decide whether an incoming request should be handled as a static asset. If an application configures a static URL prefix such as `/css`, Rack versions before 2.2.23, 3.1.21, and 3.2.6 may also treat paths like `/css-config.env`, `/css-backup.sql`, or other same-prefix filenames as static content. When such files exist under the configured static root, a remote unauthenticated attacker can retrieve them over HTTP. The flaw is limited to confidentiality impact: it does not directly enable code execution, data modification, privilege escalation, or denial of service.

Why it matters to the business

An exposed application may unintentionally publish sensitive files such as environment files, backups, configuration fragments, database dumps, credentials, API keys, or internal documentation if those files are stored under the static root and share a configured static prefix. Although this vulnerability is not currently in CISA KEV and has low EPSS, it is network-exploitable without authentication and can produce high-impact data exposure when sensitive files are present.

How an attack unfolds

An attacker first identifies a Ruby application using vulnerable Rack static file handling and determines likely configured static prefixes, commonly paths such as `/css`, `/js`, `/images`, or `/assets`. The attacker then sends crafted HTTP GET requests for filenames that begin with those prefixes but are not intended static assets, such as `/css-config.env`, `/js-backup.sql`, or `/assets-secrets.yml`. Because vulnerable Rack::Static only checks whether the request path starts with the configured prefix, it may route the request to the static file server. If a matching file exists under the static root, the server returns its contents to the attacker. The attacker can then use disclosed secrets, configuration values, source fragments, or database exports to support follow-on compromise, credential theft, or lateral movement.

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 direct package version data is unavailable from dependency tooling, inspect the resolved Rack version in the application lockfile and rebuild/redeploy with a patched version. As a defense-in-depth measure, remove sensitive files from static roots, ensure backups, `.env` files, database dumps, credentials, and configuration files are never stored below publicly served directories, and configure web servers or application middleware to deny access to high-risk extensions such as `.env`, `.sql`, `.yml`, `.yaml`, `.bak`, `.backup`, `.old`, `.zip`, `.tar`, and `.gz`. Where immediate upgrade is not possible, change static URL prefixes to include explicit path boundaries where supported, add routing or reverse-proxy deny rules for same-prefix sensitive filenames, and audit the static root for unintended files.

How to confirm the fix worked

Confirm the application is running Rack 2.2.23, 3.1.21, 3.2.6, or newer, depending on the branch in use. Review dependency manifests and lockfiles such as `Gemfile.lock` to verify the resolved `rack` gem version, then confirm the deployed artifact contains the same version. Test affected static prefixes by placing or using a non-sensitive canary file under the static root with a same-prefix but non-directory-style name, then request it over HTTP; patched behavior should not serve unintended same-prefix files solely because their names begin with the configured prefix. Also run an exposure audit of the static root to confirm no secrets, backups, dumps, or environment files are present and verify that reverse-proxy or application deny rules block risky file extensions.

Typical attack path

1. Identify a Rack-based Ruby web application exposed over HTTP or HTTPS.
2. Infer configured static URL prefixes such as `/css`, `/js`, `/images`, or `/assets`.
3. Probe similarly prefixed filenames that may contain sensitive data, for example `/css-config.env`, `/css-backup.sql`, `/js-secrets.yml`, or `/assets-dump.sql`.
4. Review HTTP responses for unexpected 200 responses, non-asset content types, or file contents containing credentials, configuration, backups, or database data.
5. Use any exposed secrets or internal information for follow-on attacks against the application, infrastructure, or third-party services.

How to detect it

Review web server, reverse-proxy, CDN, load balancer, and application access logs for requests to paths that begin with configured static prefixes but are not normal asset paths, especially successful HTTP 200 responses. Focus on requests for same-prefix filenames containing sensitive terms or extensions such as `.env`, `.sql`, `.yml`, `.yaml`, `.bak`, `.backup`, `.old`, `.zip`, `.tar`, `.gz`, `config`, `secret`, `dump`, `backup`, `database`, or `credentials`. Compare requested paths against the expected static asset inventory; unexpected successful downloads are the strongest exploitation signal. Investigate unusual response sizes, non-asset MIME types, repeated enumeration of similarly named files, and requests from single IPs scanning many static-prefix variants. If exposure is suspected, preserve access logs, identify exact files returned, determine whether their contents contained secrets or regulated data, and rotate any exposed credentials.

• GET /css-config.env
• GET /css.env
• GET /css-backup.sql
• GET /css_backup.sql
• GET /css-dump.sql
• GET /css-secrets.yml
• GET /css-credentials.yml
• GET /css.bak
• GET /css-backup.zip
• GET /js-config.env
• GET /js.env
• GET /js-backup.sql
• GET /js_backup.sql
• GET /js-dump.sql
• GET /js-secrets.yml
• GET /js-credentials.yml
• GET /js.bak
• GET /js-backup.zip
• GET /assets-config.env
• GET /assets.env
• GET /assets-backup.sql
• GET /assets_backup.sql
• GET /assets-dump.sql
• GET /assets-secrets.yml
• GET /assets-credentials.yml
• GET /assets.bak
• GET /assets-backup.zip
• GET /images-config.env
• GET /images.env
• GET /images-backup.sql
• GET /images_backup.sql
• GET /images-dump.sql
• GET /images-secrets.yml
• GET /images-credentials.yml
• GET /images.bak
• GET /images-backup.zip

What your security team should do

• Prioritize upgrading Rack to 2.2.23, 3.1.21, 3.2.6, or later in all Ruby applications that use Rack::Static.
• Inventory externally reachable Ruby/Rack applications and identify those serving static files from application-controlled directories.
• Audit static roots for sensitive files, especially files whose names begin with common static prefixes such as `css`, `js`, `images`, or `assets`.
• Add web server, CDN, WAF, or application-layer blocks for sensitive file extensions and common backup/configuration filenames.
• Review HTTP access logs for successful requests to suspicious same-prefix paths and sensitive extensions.
• If secrets or configuration files may have been exposed, rotate affected credentials, API keys, database passwords, signing secrets, and tokens.
• Add CI/CD checks to prevent `.env`, backups, database dumps, credentials, and other sensitive artifacts from being packaged into public static directories.