Update dependency rack to v3.2.2 [SECURITY] (#676)

This PR contains the following updates:

| Package | Change | Age | Confidence |
|---|---|---|---|
| [rack](https://redirect.github.com/rack/rack)
([changelog](https://redirect.github.com/rack/rack/blob/main/CHANGELOG.md))
| `3.2.1` -> `3.2.2` |
[![age](https://developer.mend.io/api/mc/badges/age/rubygems/rack/3.2.2?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
[![confidence](https://developer.mend.io/api/mc/badges/confidence/rubygems/rack/3.2.1/3.2.2?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|

### GitHub Vulnerability Alerts

####
[CVE-2025-61770](https://redirect.github.com/rack/rack/security/advisories/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.

####
[CVE-2025-61771](https://redirect.github.com/rack/rack/security/advisories/GHSA-w9pc-fmgc-vxvw)

## Summary

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

## Details

During multipart parsing, file parts are streamed to temporary files,
but non-file parts are buffered into memory:

```ruby
body = String.new  # non-file → in-RAM buffer
@&#8203;mime_parts[mime_index].body << content
```

There is no size limit on these in-memory buffers. As a result, any
large text field—while technically valid—will be loaded fully into
process memory before being added to `params`.

## Impact

Attackers can send large non-file fields to trigger excessive memory
usage. Impact scales with request size and concurrency, potentially
leading to worker crashes or severe garbage-collection overhead. All
Rack applications processing multipart form submissions are affected.

## Mitigation

* **Upgrade:** Use a patched version of Rack that enforces a reasonable
size cap for non-file fields (e.g., 2 MiB).
* **Workarounds:**
* Restrict maximum request body size at the web-server or proxy layer
(e.g., Nginx `client_max_body_size`).
* Validate and reject unusually large form fields at the application
level.

####
[CVE-2025-61772](https://redirect.github.com/rack/rack/security/advisories/GHSA-wpv5-97wm-hp9c)

## Summary

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

## Details

While reading multipart headers, the parser waits for `CRLFCRLF` using:

```ruby
@&#8203;sbuf.scan_until(/(.*?\r\n)\r\n/m)
```

If the terminator never appears, it continues appending data
(`@sbuf.concat(content)`) indefinitely. There is no limit on accumulated
header bytes, so a single malformed part can consume memory proportional
to the request body size.

## Impact

Attackers can send incomplete multipart headers to trigger high memory
use, leading to process termination (OOM) or severe slowdown. The effect
scales with request size limits and concurrency. All applications
handling multipart uploads may be affected.

## Mitigation

* Upgrade to a patched Rack version that caps per-part header size
(e.g., 64 KiB).
* Until then, restrict maximum request sizes at the proxy or web server
layer (e.g., Nginx `client_max_body_size`).

---

### Release Notes

<details>
<summary>rack/rack (rack)</summary>

###
[`v3.2.2`](https://redirect.github.com/rack/rack/blob/HEAD/CHANGELOG.md#322---2025-10-07)

[Compare
Source](https://redirect.github.com/rack/rack/compare/v3.2.1...v3.2.2)

##### Security

-
[CVE-2025-61772](https://redirect.github.com/advisories/GHSA-wpv5-97wm-hp9c)
Multipart parser buffers unbounded per-part headers, enabling DoS
(memory exhaustion)
-
[CVE-2025-61771](https://redirect.github.com/advisories/GHSA-w9pc-fmgc-vxvw)
Multipart parser buffers large non‑file fields entirely in memory,
enabling DoS (memory exhaustion)
-
[CVE-2025-61770](https://redirect.github.com/advisories/GHSA-p543-xpfm-54cp)
Unbounded multipart preamble buffering enables DoS (memory exhaustion)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "" in timezone Asia/Tokyo, Automerge -
At any time (no schedule defined).

🚦 **Automerge**: Enabled.

♻ **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/line/line-bot-sdk-ruby).

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS4xMzEuOSIsInVwZGF0ZWRJblZlciI6IjQxLjEzMS45IiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbImRlcGVuZGVuY3kgdXBncmFkZSJdfQ==-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Author: renovate[bot]

Gemfile.lock

@@ -58,7 +58,7 @@ GEM
     prism (1.5.1)
     public_suffix (6.0.1)
     racc (1.8.1)
-    rack (3.2.1)
+    rack (3.2.2)
     rackup (2.2.1)
       rack (>= 3)
     rainbow (3.1.1)