CVE-2026-34830

What it actually does

The flaw is an information disclosure vulnerability in Rack::Sendfile when used with nginx X-Accel-Redirect support. Vulnerable Rack versions interpolate the untrusted X-Accel-Mapping request header directly into a regular expression while translating backend filesystem paths into X-Accel-Redirect paths. Because regex metacharacters are not escaped, an attacker able to send or preserve this header to the Rack application can influence the path-rewrite logic and cause the application to emit an attacker-controlled X-Accel-Redirect response header. In deployments where nginx honors that header for protected internal locations, nginx may serve files that were not intended to be reachable by the requester. The issue affects Rack prior to 2.2.23, 3.1.21, and 3.2.6 and primarily impacts confidentiality; integrity and availability are not directly affected.

Why it matters to the business

Organizations running Ruby applications on vulnerable Rack versions may unintentionally expose files that are normally protected behind nginx internal locations, such as private downloads, generated exports, cached documents, or application-managed files. The practical risk depends heavily on deployment architecture: the application must use Rack::Sendfile with x-accel-redirect and must allow an attacker-supplied X-Accel-Mapping header to reach the backend. Although the CVSS confidentiality impact is high, exploitation complexity is high, EPSS is low, the vulnerability is not listed in CISA KEV, and no public exploit maturity is indicated, so remediation should be prioritized for internet-facing Ruby applications using nginx accelerated file serving rather than treated as broad emergency patching.

How an attack unfolds

An attacker first identifies a Ruby web application backed by Rack that uses Rack::Sendfile with nginx X-Accel-Redirect for file delivery. The attacker then determines whether the frontend proxy or load balancer forwards the X-Accel-Mapping request header to the backend application instead of stripping it. If the header reaches the vulnerable Rack code, the attacker sends a crafted X-Accel-Mapping value containing regex metacharacters that alter the regular expression Rack builds during path rewriting. When the application processes a sendfile response, Rack uses the attacker-influenced mapping and emits an X-Accel-Redirect header pointing to an unintended internal nginx location or file path. nginx then processes the response header and may serve the referenced internal file to the attacker, bypassing the application’s intended authorization checks. Exploitation is constrained to deployments with this specific Rack/nginx configuration and useful internal file mappings.

How to fix it

Upgrade Rack to a patched version: 2.2.23 or later for the 2.2.x line, 3.1.21 or later for the 3.1.x line, or 3.2.6 or later for the 3.2.x line. If package manifests allow broad dependency resolution, run the appropriate dependency update process and verify the resolved Rack version, because Rack is commonly included transitively by Ruby web frameworks. As a defense-in-depth mitigation, strip untrusted X-Accel-Mapping request headers at nginx, reverse proxies, CDNs, API gateways, and load balancers before traffic reaches the application. Only allow the application itself to generate X-Accel-Redirect response headers. Review nginx internal location rules to ensure they cannot expose sensitive filesystem paths through overly broad aliases or roots. If immediate upgrade is not possible, disable Rack::Sendfile x-accel-redirect behavior where feasible or replace dynamic header-based mappings with static, trusted configuration.

How to confirm the fix worked

Confirm remediation by checking the installed Rack version in each Ruby application runtime and build artifact. For Bundler-based applications, inspect Gemfile.lock or run `bundle exec ruby -e 'require "rack"; puts Rack.release'` and verify the version is 2.2.23, 3.1.21, 3.2.6, or newer depending on the release line. Validate dependency scanners and SBOMs no longer report vulnerable Rack versions below those thresholds. Review nginx, proxy, CDN, and gateway configuration to confirm client-supplied X-Accel-Mapping headers are removed before upstream forwarding. Perform a controlled test by sending a request with a benign X-Accel-Mapping header and verifying that the backend does not receive it or that it cannot affect any X-Accel-Redirect response. Also confirm nginx internal locations are inaccessible directly from clients and only reachable through trusted application-generated redirects.

Typical attack path

1. Identify a Ruby/Rack application that appears to use nginx accelerated file serving or protected download endpoints.
2. Test whether the frontend accepts and forwards the X-Accel-Mapping request header to the Rack backend.
3. Send requests containing crafted X-Accel-Mapping header values with regex metacharacters designed to influence Rack::Sendfile path mapping.
4. Trigger an application route that returns a file response processed by Rack::Sendfile.
5. Cause the backend to emit an attacker-controlled or attacker-influenced X-Accel-Redirect response header.
6. Have nginx serve an unintended file from an internal location that should not be directly accessible.
7. Repeat with adjusted mappings and paths to enumerate or retrieve additional protected files.

How to detect it

To determine whether exploitation was attempted or successful, review edge proxy, load balancer, CDN, nginx, and application access logs for inbound requests containing the X-Accel-Mapping header. Pay special attention to values containing regex metacharacters such as `.*`, `(.+)`, `|`, `^`, `$`, escaped groups, or suspicious path manipulation. Correlate such requests with backend responses that include X-Accel-Redirect and with nginx access log entries serving files from internal locations shortly afterward. If response headers are logged, search for unexpected X-Accel-Redirect values or redirects to internal paths that do not match normal application behavior. Where available, inspect application logs around file download endpoints for anomalous requested filenames, unusually broad file mappings, authorization failures followed by successful file responses, or downloads of sensitive file types. On nginx, compare request URI, authenticated user context if logged, upstream response headers, and final served file path to detect cases where nginx served internal files not normally reachable for that route. Since there are no widely published exploit indicators, detection should focus on the suspicious header name, regex-like header content, and abnormal internal file delivery patterns.

• X-Accel-Mapping
• X-Accel-Redirect
• HTTP_X_ACCEL_MAPPING
• X-Accel-Mapping: .*
• X-Accel-Mapping: (.*)
• X-Accel-Mapping: (.+)
• X-Accel-Mapping: ^
• X-Accel-Mapping: $
• X-Accel-Mapping: |
• X-Accel-Mapping: ../
• X-Accel-Mapping: ..%2f
• X-Accel-Mapping: %2e%2e%2f
• upstream_http_x_accel_redirect
• sent_http_x_accel_redirect

What your security team should do

• Inventory Ruby applications and container images that include Rack, especially internet-facing services using nginx for accelerated file delivery.
• Prioritize upgrades for applications using Rack::Sendfile with x-accel-redirect; move to Rack 2.2.23, 3.1.21, 3.2.6, or later.
• Add or verify proxy-layer rules that strip inbound X-Accel-Mapping headers from all external requests before they reach application backends.
• Search access logs and application logs for requests containing X-Accel-Mapping, particularly values with regex metacharacters or path traversal-like content.
• Review nginx internal location, alias, and root directives for overly broad file exposure if X-Accel-Redirect is misdirected.
• Add regression tests or security tests ensuring user-supplied headers cannot influence X-Accel-Redirect output.
• Because EPSS is low and there is no KEV listing or known exploit maturity, prioritize based on exposure and use of the vulnerable feature rather than Rack presence alone.