Rack CVE-2025-61780

Exploitable only when ALL of the following hold: (1) the application uses Rack::Sendfile middleware behind a proxy that honors x-accel-redirect, specifically Nginx; (2) the proxy is NOT configured to always set or strip the client-supplied 'x-sendfile-type' and 'x-accel-mapping' request headers (i.e., it passes them through from the client); and (3) the application exposes at least one endpoint whose response body responds to .to_path, qualifying it for sendfile acceleration. The attack is remote and unauthenticated (PR:N) but tightly limited by this non-default header-passthrough configuration - correctly configured proxies that strip or pin these headers, applications not using Rack::Sendfile, or versions >= 2.2.20/3.1.18/3.2.3 (which ignore the request header and require explicit 'use Rack::Sendfile, "x-accel-redirect"' configuration) are not exploitable. Impact is limited to disclosure/access of protected internal routes, not arbitrary file read.

This is a genuine but conditional, moderate-risk issue - not a top-priority emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, base 5.3) models a network-reachable, unauthenticated attack with only limited confidentiality impact and no integrity or availability impact, which matches the advisory's statement that it exposes protected routes but does NOT permit arbitrary file reads. However, the low-complexity rating (AC:L) understates reality: the advisory and source diff confirm exploitation requires a specific stack (Rack::Sendfile behind an x-accel-redirect-capable proxy such as Nginx), a proxy that fails to set/strip the x-sendfile-type and x-accel-mapping headers, and an app endpoint whose body responds to .to_path - so a more honest complexity is high. All corroborating-threat signals point to low urgency: EPSS is 0.55% (45th percentile), there is no CISA KEV listing, and no public exploit code is referenced in the inputs. No SSVC decision data was provided. The signals are internally consistent (low EPSS, no KEV, limited scalar impact), so this is best treated as a patch-in-normal-cycle hygiene item rather than an actively-exploited threat - prioritize it where the vulnerable Nginx/Rack::Sendfile configuration is actually present.

An attacker sends an HTTP request to a Rack application sitting behind Nginx, injecting a crafted 'x-sendfile-type: x-accel-redirect' header together with a crafted 'x-accel-mapping' header, and targets a path that qualifies for proxy-based acceleration. Rack::Sendfile trusts these client-supplied headers as proxy configuration and emits an X-Accel-Redirect response, causing Nginx to reissue an internal request that bypasses its access controls and reaches administrative or otherwise protected routes. No public exploit code is identified in the provided data, and success depends on the proxy not stripping these headers.