CVE-2025-61780

What it actually does

The flaw affects Rack::Sendfile when Rack applications run behind a reverse proxy that honors sendfile-style headers such as Nginx X-Accel-Redirect or X-Sendfile. By supplying specially crafted request headers, an attacker may influence how Rack::Sendfile selects or maps the proxy offload mechanism, causing the application and proxy to disagree about what internal URI or file should be served. In vulnerable deployments, this can trigger unintended proxy-internal requests and may bypass access controls enforced only at the proxy layer, resulting in disclosure of files or internal routes that should not be directly reachable. The issue is configuration-dependent and requires use of Rack::Sendfile with a compatible proxy sendfile feature.

Why it matters to the business

Successful exploitation could expose restricted files, protected downloads, or internal proxy locations that the application owner expected to be inaccessible without authorization. The practical impact is data exposure rather than code execution, but affected applications may handle sensitive documents, generated exports, customer uploads, or internal-only assets. The vulnerability is not currently listed in CISA KEV, has no reported ransomware association, and has a low EPSS score, but it has been public for an extended period, so internet-facing Rack applications using sendfile proxy integration should still be reviewed and patched during normal vulnerability remediation cycles.

How an attack unfolds

An attacker first identifies a Rack-based web application behind a proxy that supports sendfile delegation, such as Nginx X-Accel-Redirect or X-Sendfile. The attacker then sends requests containing crafted sendfile-related headers, especially headers that influence Rack::Sendfile behavior or path mapping. If the application trusts these headers or allows them to reach Rack::Sendfile, the middleware may emit a proxy sendfile response that causes the front-end proxy to make an unintended internal request. If the proxy relies on internal locations or sendfile redirects for access control, the attacker may receive content that would normally be blocked by proxy rules. Exploitation does not require authentication in the worst case if the vulnerable endpoint is reachable anonymously, but the exposed content depends on application routes, file-serving behavior, and proxy configuration.

How to fix it

Upgrade rack/rack to a version containing commit 6ef591522bb44f80654ad1a80654ba46cafdc7c1 or a downstream release that includes that fix. Because the provided fixed version is a Git commit rather than a package version, verify the exact Rack gem or distribution version used by the application includes this commit. As defense in depth, configure the front-end proxy to strip untrusted client-supplied sendfile control headers before forwarding requests to the application, including X-Sendfile-Type, X-Sendfile, X-Accel-Redirect, and X-Accel-Mapping unless explicitly required from a trusted component. Review Nginx internal locations and X-Accel-Redirect/X-Sendfile mappings to ensure proxy-only paths are not reachable from untrusted input. Avoid relying solely on proxy-level restrictions for authorization decisions; enforce authorization in the application before returning file-send responses.

How to confirm the fix worked

Confirm the deployed Rack code contains commit 6ef591522bb44f80654ad1a80654ba46cafdc7c1 or a vendor release that includes it. Inventory applications using Rack::Sendfile and identify whether they run behind Nginx, Apache/lighttpd modules, or other proxies that honor X-Sendfile-style headers. Test that externally supplied X-Sendfile-Type, X-Sendfile, X-Accel-Redirect, and X-Accel-Mapping headers are stripped or ignored before reaching the Rack application. Perform a controlled negative test against file-download endpoints by sending these headers and confirming the response does not expose alternate files, proxy internal locations, or different behavior. Review proxy configuration for internal-only locations and verify direct external requests to those paths return deny/404 behavior.

Typical attack path

1. Reconnaissance identifies a Ruby/Rack application served through a proxy that supports X-Sendfile or X-Accel-Redirect behavior.
2. The attacker probes endpoints that return downloadable files, static assets, generated exports, or protected media.
3. The attacker submits requests with crafted sendfile-related headers such as X-Sendfile-Type or X-Accel-Mapping.
4. Rack::Sendfile processes the request and miscommunicates sendfile instructions to the proxy.
5. The proxy performs an unintended internal redirect or file-serving action.
6. The attacker receives content from a restricted internal location or file path that should have required authorization or should not have been externally reachable.

How to detect it

To determine whether exploitation already occurred, review reverse proxy, web server, application, and WAF logs for requests containing client-supplied sendfile-related headers. Key log sources include Nginx or other reverse proxy access/error logs, Rack/Ruby application request logs, WAF request-header logs, CDN edge logs if headers are retained, and any audit logs for file-download endpoints. Focus on requests to download, media, export, attachment, or protected-file endpoints that include X-Sendfile-Type, X-Accel-Mapping, X-Accel-Redirect, or X-Sendfile headers. Compare response status codes and byte counts against normal behavior; successful exploitation may appear as ordinary 200 responses with unusual response sizes or access to internal/protected URI patterns. If proxy logs do not record request headers, check WAF/CDN logs or reproduce logging in a lab to understand whether header evidence would have been retained. Also inspect proxy error logs for abnormal internal redirect behavior, failed internal location lookups, or attempts to access internal-only aliases. There are no public threat actors or mature exploit campaigns associated with this issue in the provided data, so detection should focus on anomalous header use and unexpected access to protected file-serving paths rather than named actor tooling.

• X-Sendfile-Type
• X-Sendfile
• X-Accel-Redirect
• X-Accel-Mapping
• HTTP_X_SENDFILE_TYPE
• HTTP_X_ACCEL_MAPPING
• x-sendfile-type:
• x-sendfile:
• x-accel-redirect:
• x-accel-mapping:
• Rack::Sendfile
• X-Accel-Redirect:
• X-Sendfile-Type:

What your security team should do

• Prioritize externally reachable Rack applications that use Rack::Sendfile behind Nginx or another sendfile-capable reverse proxy.
• Upgrade rack/rack to a release containing commit 6ef591522bb44f80654ad1a80654ba46cafdc7c1, and verify lockfiles, container images, and deployed artifacts are rebuilt with the fixed dependency.
• Add proxy rules to drop untrusted inbound sendfile-related headers before requests reach application servers.
• Audit protected download and file-serving flows to ensure authorization is enforced in application code and not only through proxy internal locations.
• Enable or temporarily enhance access logging to capture suspicious inbound headers during the remediation window.
• Search historical logs for requests containing X-Sendfile-Type, X-Accel-Mapping, X-Sendfile, or X-Accel-Redirect headers, especially against download or media endpoints.
• If suspicious activity is found, identify the requested resources, user/session context if available, response status and size, and whether restricted content may have been returned.