Improper handling of proxy headers in Rack::Sendfile may allow proxy bypass.

- Ignore `HTTP_X_SENDFILE_TYPE` header from requests to prevent attackers from enabling sendfile features.
- Only read `HTTP_X_ACCEL_MAPPING` when `x-accel-redirect` is explicitly configured and no app-level mappings exist.
- Prefer `\A` instead of `^` to match the start of path mappings.

Author: ioquatix

CHANGELOG.md

@@ -2,6 +2,12 @@
 
 All notable changes to this project will be documented in this file. For info on how to format all future additions to this file please reference [Keep A Changelog](https://keepachangelog.com/en/1.0.0/).
 
+## [3.1.18] - 2025-10-10
+
+### Security
+
+- [CVE-2025-61780](https://github.com/advisories/GHSA-r657-rxjc-j557) Improper handling of headers in `Rack::Sendfile` may allow proxy bypass.
+
 ## [3.1.17] - 2025-10-07
 
 ### Security
@@ -373,6 +379,13 @@ Rack v3.1 is primarily a maintenance release that removes features deprecated in
 - Fix multipart filename generation for filenames that contain spaces. Encode spaces as "%20" instead of "+" which will be decoded properly by the multipart parser. ([#1736](https://github.com/rack/rack/pull/1645), [@muirdm](https://github.com/muirdm))
 - `Rack::Request#scheme` returns `ws` or `wss` when one of the `X-Forwarded-Scheme` / `X-Forwarded-Proto` headers is set to `ws` or `wss`, respectively. ([#1730](https://github.com/rack/rack/issues/1730), [@erwanst](https://github.com/erwanst))
 
+## [2.2.20] - 2025-10-10
+
+### Security
+
+- [CVE-2025-61780](https://github.com/advisories/GHSA-r657-rxjc-j557) Improper handling of headers in `Rack::Sendfile` may allow proxy bypass.
+- [CVE-2025-61919](https://github.com/advisories/GHSA-6xw4-3v39-52mm) Unbounded read in `Rack::Request` form parsing can lead to memory exhaustion.
+
 ## [2.2.19] - 2025-10-07
 
 ### Security

lib/rack/sendfile.rb

@@ -16,21 +16,21 @@ module Rack
   # delivery code.
   #
   # In order to take advantage of this middleware, the response body must
-  # respond to +to_path+ and the request must include an x-sendfile-type
+  # respond to +to_path+ and the request must include an `x-sendfile-type`
   # header. Rack::Files and other components implement +to_path+ so there's
-  # rarely anything you need to do in your application. The x-sendfile-type
+  # rarely anything you need to do in your application. The `x-sendfile-type`
   # header is typically set in your web servers configuration. The following
   # sections attempt to document
   #
   # === Nginx
   #
-  # Nginx supports the x-accel-redirect header. This is similar to x-sendfile
+  # Nginx supports the `x-accel-redirect` header. This is similar to `x-sendfile`
   # but requires parts of the filesystem to be mapped into a private URL
   # hierarchy.
   #
   # The following example shows the Nginx configuration required to create
-  # a private "/files/" area, enable x-accel-redirect, and pass the special
-  # x-sendfile-type and x-accel-mapping headers to the backend:
+  # a private "/files/" area, enable `x-accel-redirect`, and pass the special
+  # `x-accel-mapping` header to the backend:
   #
   #   location ~ /files/(.*) {
   #     internal;
@@ -44,24 +44,29 @@ module Rack
   #     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/;
   #
   #     proxy_pass         http://127.0.0.1:8080/;
   #   }
   #
-  # Note that the x-sendfile-type header must be set exactly as shown above.
-  # The x-accel-mapping header should specify the location on the file system,
+  # 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.
+  #
   # See Also: https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile
   #
   # === lighttpd
   #
-  # Lighttpd has supported some variation of the x-sendfile header for some
-  # time, although only recent version support x-sendfile in a reverse proxy
+  # Lighttpd has supported some variation of the `x-sendfile` header for some
+  # time, although only recent version support `x-sendfile` in a reverse proxy
   # configuration.
   #
   #   $HTTP["host"] == "example.com" {
@@ -83,7 +88,7 @@ module Rack
   #
   # === Apache
   #
-  # x-sendfile is supported under Apache 2.x using a separate module:
+  # `x-sendfile` is supported under Apache 2.x using a separate module:
   #
   # https://tn123.org/mod_xsendfile/
   #
@@ -97,16 +102,28 @@ module Rack
   # === Mapping parameter
   #
   # The third parameter allows for an overriding extension of the
-  # x-accel-mapping header. Mappings should be provided in tuples of internal to
+  # `x-accel-mapping` header. Mappings should be provided in tuples of internal to
   # external. The internal values may contain regular expression syntax, they
   # will be matched with case indifference.
+  #
+  # When `x-accel-redirect` is explicitly enabled via the variation parameter,
+  # and no application-level mappings are provided, the middleware will read
+  # the `x-accel-mapping` header from the proxy. This allows nginx to control
+  # the path mapping without requiring application-level configuration.
+  #
+  # === Security
+  #
+  # For security reasons, the `x-sendfile-type` header from HTTP requests is
+  # ignored. The sendfile variation must be explicitly configured via the
+  # middleware constructor to prevent information disclosure vulnerabilities
+  # where attackers could bypass proxy restrictions.
 
   class Sendfile
     def initialize(app, variation = nil, mappings = [])
       @app = app
       @variation = variation
       @mappings = mappings.map do |internal, external|
-        [/^#{internal}/i, external]
+        [/\A#{internal}/i, external]
       end
     end
 
@@ -145,22 +162,35 @@ def call(env)
     end
 
     private
+
     def variation(env)
-      @variation ||
-        env['sendfile.type'] ||
-        env['HTTP_X_SENDFILE_TYPE']
+      # Note: HTTP_X_SENDFILE_TYPE is intentionally NOT read for security reasons.
+      # Attackers could use this header to enable x-accel-redirect and bypass proxy restrictions.
+      @variation || env['sendfile.type']
+    end
+
+    def x_accel_mapping(env)
+      # Only allow header when:
+      # 1. `x-accel-redirect` is explicitly enabled via constructor.
+      # 2. No application-level mappings are configured.
+      return nil unless @variation =~ /x-accel-redirect/i
+      return nil if @mappings.any?
+      
+      env['HTTP_X_ACCEL_MAPPING']
     end
 
     def map_accel_path(env, path)
       if mapping = @mappings.find { |internal, _| internal =~ path }
-        path.sub(*mapping)
-      elsif mapping = env['HTTP_X_ACCEL_MAPPING']
+        return path.sub(*mapping)
+      elsif mapping = x_accel_mapping(env)
+        # Safe to use header: explicit config + no app mappings:
         mapping.split(',').map(&:strip).each do |m|
           internal, external = m.split('=', 2).map(&:strip)
-          new_path = path.sub(/^#{internal}/i, external)
+          new_path = path.sub(/\A#{internal}/i, external)
           return new_path unless path == new_path
         end
-        path
+
+        return path
       end
     end
   end