Package Instance

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

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

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.

Stored XSS in Rack::Directory via javascript: filenames rendered into anchor href
## Summary

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

## Details

`Rack::Directory` renders directory entries using an HTML row template similar to:

```html
<a href='%s'>%s</a>
```

The `%s` placeholder is populated directly with the file’s basename. If the basename begins with `javascript:`, the resulting HTML contains an executable JavaScript URL:

```html
<a href='javascript:alert(1)'>javascript:alert(1)</a>
```

Because the value is inserted directly into the `href` attribute without scheme validation or normalization, browsers interpret it as a JavaScript URI. When a user clicks the link, the JavaScript executes in the origin of the Rack application.

## Impact

If `Rack::Directory` is used to expose filesystem contents over HTTP, an attacker who can create or upload files within that directory may introduce a malicious filename beginning with `javascript:`.

When a user visits the directory listing and clicks the entry, arbitrary JavaScript executes in the application's origin. Exploitation requires user interaction (clicking the malicious entry).

## Mitigation

* Update to a patched version of Rack in which `Rack::Directory` prefixes generated anchors with a relative path indicator (e.g. `./filename`).
* Avoid exposing user-controlled directories via `Rack::Directory`.
* Apply a strict Content Security Policy (CSP) to reduce impact of potential client-side execution issues.
* Where feasible, restrict or sanitize uploaded filenames to disallow dangerous URI scheme prefixes.

HackerOne profile:
https://hackerone.com/thesmartshadow

GitHub account owner:
Ali Firas (@thesmartshadow)