CVE-2025-61780
BaseFortify
Publication date: 2025-10-10
Last updated on: 2025-10-30
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| rack | rack | to 2.2.20 (exc) |
| rack | rack | From 3.0.0 (inc) to 3.1.18 (exc) |
| rack | rack | From 3.2.0 (inc) to 3.2.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-441 | The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. |
| CWE-200 | The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. |
| CWE-913 | The product does not properly restrict reading from or writing to dynamically-managed code resources such as variables, objects, classes, attributes, functions, or executable instructions or statements. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-61780 is a vulnerability in the Rack Ruby webserver interface's `Rack::Sendfile` middleware. It occurs when the middleware improperly handles certain HTTP headers (`x-sendfile-type` and `x-accel-mapping`) sent by clients when running behind a proxy that supports x-sendfile headers (like Nginx). Attackers can craft these headers to trick `Rack::Sendfile` into treating them as proxy configuration directives, causing the proxy to make internal requests that bypass access controls. This can expose sensitive internal application routes, such as administrative pages, although it does not allow arbitrary file reads. The vulnerability arises because the middleware accepted these headers directly from clients instead of requiring explicit configuration. The issue affects systems using `Rack::Sendfile` with proxies that do not always set or remove these headers and expose endpoints returning bodies responding to `.to_path`. The fix involves ignoring these headers from client requests and requiring explicit middleware configuration to enable sendfile features. [1, 2, 3, 4]
How can this vulnerability impact me? :
This vulnerability can allow an attacker to bypass proxy-level access restrictions by sending specially crafted HTTP headers. As a result, the attacker may gain unauthorized access to internal application routes that are intended to be protected by the proxy, such as administrative pages or other sensitive endpoints. Although the vulnerability does not permit arbitrary file reads or modification, it can lead to information disclosure of sensitive application routes. This can compromise the confidentiality of internal resources and potentially aid further attacks. [1, 2, 3, 4]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection involves monitoring HTTP requests for the presence of suspicious or specially crafted headers such as `x-sendfile-type: x-accel-redirect` and `x-accel-mapping` being sent to your Rack-based application behind a proxy like Nginx. You can use network traffic inspection tools or web server logs to identify such headers. For example, using `tcpdump` or `ngrep` to capture HTTP headers on the relevant port and filter for these headers can help detect exploitation attempts. Example command: `sudo ngrep -d any -W byline 'x-sendfile-type|x-accel-mapping' tcp port 80 or tcp port 443`. Additionally, reviewing application logs for unexpected internal redirects or proxy requests triggered by these headers may indicate exploitation attempts. [2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading the Rack middleware to versions 2.2.20, 3.1.18, or 3.2.3, which enforce explicit configuration of sendfile variations and ignore untrusted headers from clients. Alternatively, configure your proxy (e.g., Nginx) to always set or strip the `x-sendfile-type` and `x-accel-mapping` headers to prevent client manipulation. For example, in Nginx, use directives like `proxy_set_header x-sendfile-type x-accel-redirect;` and `proxy_set_header x-accel-mapping /var/www/=/files/;`. If using Rails, disable sendfile by setting `config.action_dispatch.x_sendfile_header = nil`. These steps prevent attackers from exploiting the vulnerability by controlling the relevant headers. [1, 2, 4]