GHSA-p543-xpfm-54cp

## Summary

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

## Details

While searching for the first boundary, the parser appends incoming data into a shared buffer (`@sbuf.concat(content)`) and scans for the boundary pattern:

```ruby @sbuf.scan_until(@body_regex) ```

If the boundary is not yet found, the parser continues buffering data indefinitely. There is no trimming or size cap on the preamble, allowing attackers to send arbitrary amounts of data before the first boundary.

## Impact

Remote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to garbage collection.

## Mitigation

* **Upgrade:** Use a patched version of Rack that enforces a preamble size limit (e.g., 16 KiB) or discards preamble data entirely per [RFC 2046 § 5.1.1](https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1.1). * **Workarounds:** * Limit total request body size at the proxy or web server level. * Monitor memory and set per-process limits to prevent OOM conditions.