Package Instance

Rack has an Unbounded-Parameter DoS in Rack::QueryParser
## Summary

`Rack::QueryParser` parses query strings and `application/x-www-form-urlencoded` bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters.

## Details

The vulnerability arises because `Rack::QueryParser` iterates over each `&`-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing.

## Impact

An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted.

## Mitigation

- Update to a version of Rack that limits the number of parameters parsed, or
- Use middleware to enforce a maximum query string size or parameter count, or
- Employ a reverse proxy (such as Nginx) to limit request sizes and reject oversized query strings or bodies.

Limiting request body sizes and query string lengths at the web server or CDN level is an effective mitigation.

Escape Sequence Injection vulnerability in Rack lead to Possible Log Injection
## Summary

`Rack::Sendfile` can be exploited by crafting input that includes newline characters to manipulate log entries.

## Details

The `Rack::Sendfile` middleware logs unsanitized header values from the `X-Sendfile-Type` header. An attacker can exploit this by injecting escape sequences (such as newline characters) into the header, resulting in log injection.

## Impact

This vulnerability can distort log files, obscure attack traces, and complicate security auditing.

## Mitigation

- Update to the latest version of Rack, or
- Remove usage of `Rack::Sendfile`.

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 vulnerable to ReDoS in content type parsing (2nd degree polynomial)
### Summary

```ruby
module Rack
  class MediaType
    SPLIT_PATTERN = %r{\s*[;,]\s*}
```
The above regexp is subject to ReDos. 50K blank characters as a prefix to the header will take over 10s to split.

### PoC

A simple HTTP request with lots of blank characters in the content-type header:

```ruby
request["Content-Type"] = (" " * 50_000) + "a,"
```

### Impact

It's a very easy to craft ReDoS. Like all ReDoS the impact is debatable.

Rack has a Directory Traversal via Rack:Directory
## Summary

`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.

## Details

In `directory.rb`, `File.expand_path(File.join(root, path_info)).start_with?(root)` does not enforce a path boundary. If the server root is `/var/www/root`, a path like `/var/www/root_backup` passes the check because it shares the same prefix, so `Rack::Directory` will list that directory also. 

## Impact

Information disclosure via directory listing outside the configured root when `Rack::Directory` is exposed to untrusted clients and a directory shares the root prefix (e.g., `public2`, `www_backup`).

## Mitigation

* Update to a patched version of Rack that correctly checks the root prefix.
* Don't name directories with the same prefix as one which is exposed via `Rack::Directory`.

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).