Package Instance

Rack has a Possible Information Disclosure Vulnerability
A possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions.

Rack Header Parsing leads to Possible Denial of Service Vulnerability
# Possible Denial of Service Vulnerability in Rack Header Parsing

There is a possible denial of service vulnerability in the header parsing
routines in Rack.  This vulnerability has been assigned the CVE identifier
CVE-2024-26146.

Versions Affected:  All.
Not affected:       None
Fixed Versions:     2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1

Impact
------
Carefully crafted headers can cause header parsing in Rack to take longer than
expected resulting in a possible denial of service issue. Accept and Forwarded
headers are impacted.

Ruby 3.2 has mitigations for this problem, so Rack applications using Ruby 3.2
or newer are unaffected.

Releases
--------
The fixed releases are available at the normal locations.

Workarounds
-----------
There are no feasible workarounds for this issue.

Patches
-------
To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

* 2-0-header-redos.patch - Patch for 2.0 series
* 2-1-header-redos.patch - Patch for 2.1 series
* 2-2-header-redos.patch - Patch for 2.2 series
* 3-0-header-redos.patch - Patch for 3.0 series

Credits
-------

Thanks to [svalkanov](https://hackerone.com/svalkanov) for reporting this and
providing patches!

ReDoS Vulnerability in Rack::Multipart handle_mime_head
### Summary

There is a denial of service vulnerability in the
Content-Disposition parsing component of Rack. This is very
similar to the previous security issue CVE-2022-44571.

### Details

Carefully crafted input can cause Content-Disposition header
parsing in Rack to take an unexpected amount of time, possibly
resulting in a denial of service attack vector. This header is
used typically used in multipart parsing. Any applications that
parse multipart posts using Rack (virtually all Rails applications)
are impacted.

### Credits

Thanks to [scyoon](https://hackerone.com/scyoon) for reporting
this to the Rails security team

Rack has an unsafe default in Rack::QueryParser allows params_limit bypass via semicolon-separated parameters
`Rack::QueryParser` in version `< 2.2.18` enforces its `params_limit` only for parameters separated by `&`, while still splitting on both `&` and `;`. As a result, attackers could use `;` separators to bypass the parameter count limit and submit more parameters than intended.

Rack has a Directory Traversal via Rack:Directory
`Rack::Directory`’s path check used a string prefix match on the expanded path. A request like `/../root_example/` can escape the configured root if the target path starts with the root string, allowing directory listing outside the intended root.

Possible Denial of Service Vulnerability in Rack’s header parsing
There is a denial of service vulnerability in the header parsing component of Rack. Carefully crafted input can cause header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse headers using Rack (virtually all Rails applications) are impacted. Workarounds Setting `Regexp.timeout` in Ruby 3.2 is a possible workaround.

Rack: Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)
`Rack::Multipart::Parser` stores non-file form fields (parts without a `filename`) entirely in memory as Ruby `String` objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS).

Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing
`Rack::Request#POST` reads the entire request body into memory for `Content-Type: application/x-www-form-urlencoded`, calling `rack.input.read(nil)` without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion.

Rack has possible DoS Vulnerability with Range Header
# Possible DoS Vulnerability with Range Header in Rack

There is a possible DoS vulnerability relating to the Range request header in
Rack.  This vulnerability has been assigned the CVE identifier CVE-2024-26141.

Versions Affected:  >= 1.3.0.
Not affected:       < 1.3.0
Fixed Versions:     3.0.9.1, 2.2.8.1

Impact
------
Carefully crafted Range headers can cause a server to respond with an
unexpectedly large response. Responding with such large responses could lead
to a denial of service issue.

Vulnerable applications will use the `Rack::File` middleware or the
`Rack::Utils.byte_ranges` methods (this includes Rails applications).

Releases
--------
The fixed releases are available at the normal locations.

Workarounds
-----------
There are no feasible workarounds for this issue.

Patches
-------
To aid users who aren't able to upgrade immediately we have provided patches for
the two supported release series. They are in git-am format and consist of a
single changeset.

* 3-0-range.patch - Patch for 3.0 series
* 2-2-range.patch - Patch for 2.2 series

Credits
-------

Thank you [ooooooo_q](https://hackerone.com/ooooooo_q) for the report and
patch

Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)
`Rack::Multipart::Parser` can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (`CRLFCRLF`). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS).