Package Instance

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

Duplicate
This advisory duplicates another.

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