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.

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.

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

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

Stored XSS in Rack::Directory via javascript: filenames rendered into anchor href
`Rack::Directory` generates an HTML directory index where each file entry is rendered as a clickable link. If a file exists on disk whose basename begins with the `javascript:` scheme (e.g. `javascript:alert(1)`), the generated index includes an anchor whose `href` attribute is exactly `javascript:alert(1)`. Clicking this entry executes arbitrary JavaScript in the context of the hosting application.

This results in a client-side XSS condition in directory listings generated by `Rack::Directory`.

Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)
`Rack::Multipart::Parser` buffers the entire multipart **preamble** (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions.