CVE-2025-61780: Rack Information Disclosure Vulnerability

CVE-2025-61780 Overview

CVE-2025-61780 is an information disclosure vulnerability in Rack, a modular Ruby web server interface. The flaw resides in the Rack::Sendfile middleware when deployed behind a proxy that supports x-sendfile headers, such as Nginx. Attackers can send crafted x-sendfile-type and x-accel-mapping request headers that Rack interprets as trusted proxy configuration directives. This causes the middleware to instruct the proxy to issue a new internal request that bypasses proxy-level access controls. The issue affects Rack versions prior to 2.2.20, 3.1.18, and 3.2.3 [CWE-200].

Critical Impact
Attackers can bypass proxy-enforced access restrictions and reach internal endpoints intended to be protected, such as administrative routes.

Affected Products

Rack versions prior to 2.2.20 (2.x branch)
Rack versions prior to 3.1.18 (3.1.x branch)
Rack versions prior to 3.2.3 (3.2.x branch)

Discovery Timeline

2025-10-10 - CVE-2025-61780 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-61780

Vulnerability Analysis

The Rack::Sendfile middleware accelerates file delivery by handing off transfers to a front-end proxy through x-sendfile semantics. In vulnerable versions, the middleware reads the x-sendfile-type and x-accel-mapping headers from the incoming request rather than from a trusted proxy-set configuration. When these headers arrive from an untrusted client, Rack treats them as directives from the proxy. The middleware then emits a response containing an x-accel-redirect header pointing at an internal path derived from client-supplied mapping data. The upstream proxy honors that header and reissues the request internally, bypassing location-based access control lists (ACLs) applied at the proxy edge.

Root Cause

The root cause is improper trust of client-controlled headers as proxy configuration. Rack::Sendfile did not distinguish between headers set by the proxy and headers forwarded from a remote client. Any deployment where the proxy did not explicitly strip or overwrite x-sendfile-type and x-accel-mapping inherited that trust boundary confusion.

Attack Vector

An attacker sends an HTTP request that includes x-sendfile-type: x-accel-redirect and a crafted x-accel-mapping header. The request path must target an application endpoint whose response body implements .to_path (a common pattern for file responses). Rack issues an internal redirect that the proxy re-dispatches without re-evaluating access controls, exposing protected routes such as admin interfaces. The vulnerability does not permit arbitrary file reads.

ruby

#     proxy_set_header   X-Real-IP           $remote_addr;
#     proxy_set_header   X-Forwarded-For     $proxy_add_x_forwarded_for;
#
#     proxy_set_header   X-Accel-Mapping     /var/www/=/files/;
#
#     proxy_pass         http://127.0.0.1:8080/;
#   }
#
# The X-Accel-Mapping header should specify the location on the file system,
# followed by an equals sign (=), followed name of the private URL pattern
# that it maps to. The middleware performs a simple substitution on the
# resulting path.
#
# To enable X-Accel-Redirect, you must configure the middleware explicitly:
#
#   use Rack::Sendfile, "X-Accel-Redirect"
#
# For security reasons, the X-Sendfile-Type header from requests is ignored.
# The sendfile variation must be set via the middleware constructor.

Source: Rack commit fba2c8b — lib/rack/sendfile.rb patch

The patch removes reliance on the X-Sendfile-Type request header and requires operators to opt in via the middleware constructor (use Rack::Sendfile, "X-Accel-Redirect").

Detection Methods for CVE-2025-61780

Indicators of Compromise

Inbound HTTP requests containing x-sendfile-type or x-accel-mapping headers originating from external clients.
Application access logs showing requests to sensitive internal routes (for example, /admin) with 2xx responses that do not correlate to a preceding proxy-level authentication event.
Proxy access logs showing internal sub-requests generated by x-accel-redirect responses following externally facing requests.

Detection Strategies

Inventory Ruby applications and identify those running rack versions below 2.2.20, 3.1.18, or 3.2.3 using dependency manifests such as Gemfile.lock.
Inspect proxy configuration (Nginx location blocks) to verify whether X-Sendfile-Type and X-Accel-Mapping are explicitly set by the proxy or stripped from client input.
Deploy web application firewall (WAF) or reverse-proxy rules that flag or block requests carrying x-sendfile-type or x-accel-mapping headers.

Monitoring Recommendations

Alert on any client-supplied x-sendfile-* or x-accel-* headers observed at the ingress layer.
Correlate spikes in internal x-accel-redirect handling with unauthenticated external requests to sensitive routes.
Track upgrades of the rack gem across deployment pipelines to confirm patched versions are in production.

How to Mitigate CVE-2025-61780

Immediate Actions Required

Upgrade rack to version 2.2.20, 3.1.18, or 3.2.3 depending on the branch in use.
Reconfigure Rack::Sendfile to enable x-accel-redirect explicitly via the middleware constructor: use Rack::Sendfile, "X-Accel-Redirect".
Audit proxy configuration to guarantee X-Sendfile-Type and X-Accel-Mapping are always set or stripped by the proxy, never forwarded from clients.

Patch Information

The fix is available in Rack 2.2.20, 3.1.18, and 3.2.3. The patched middleware ignores the X-Sendfile-Type header from requests and requires explicit configuration to enable x-accel-redirect. Reference commits: 57277b7, 7e69f65, and fba2c8b. See the GitHub Security Advisory GHSA-r657-rxjc-j557 for the authoritative advisory.

Workarounds

Configure the front-end proxy to always set X-Sendfile-Type and X-Accel-Mapping for upstream requests, or explicitly strip these headers from client input.
In Rails applications that do not require accelerated file delivery, disable sendfile entirely by setting config.action_dispatch.x_sendfile_header = nil.
Remove Rack::Sendfile from the middleware stack if the application does not rely on proxy-accelerated file responses.

bash

# Nginx configuration example — always set proxy headers
# and strip untrusted client-supplied variants before proxy_pass.
location / {
    proxy_set_header   X-Real-IP           $remote_addr;
    proxy_set_header   X-Forwarded-For     $proxy_add_x_forwarded_for;
    proxy_set_header   X-Sendfile-Type     X-Accel-Redirect;
    proxy_set_header   X-Accel-Mapping     /var/www/=/files/;

    # Explicitly clear any client-supplied variants
    proxy_set_header   X-Sendfile-Type     "";
    proxy_set_header   X-Accel-Mapping     "";

    proxy_pass         http://127.0.0.1:8080/;
}