🚨 [security] Update rack 3.1.12 → 3.2.2 (minor)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ rack (3.1.12 → 3.2.2) · Repo · Changelog

Security Advisories 🚨

🚨 Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)

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:

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

🚨 Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)

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:

@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.
• Workarounds:
  • Limit total request body size at the proxy or web server level.
  • Monitor memory and set per-process limits to prevent OOM conditions.

🚨 Rack: Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)

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:

body = String.new  # non-file → in-RAM buffer
@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.

🚨 Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)

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:

@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.
• Workarounds:
  • Limit total request body size at the proxy or web server level.
  • Monitor memory and set per-process limits to prevent OOM conditions.

🚨 Rack: Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)

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:

body = String.new  # non-file → in-RAM buffer
@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.

🚨 Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)

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:

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

🚨 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 for reporting this to the Rails security team

🚨 Rack has an Unbounded-Parameter DoS in Rack::QueryParser

Summary

Rack::QueryParser parses query strings and application/x-www-form-urlencoded bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters.

Details

The vulnerability arises because Rack::QueryParser iterates over each &-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing.

Impact

An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted.

Mitigation

• Update to a version of Rack that limits the number of parameters parsed, or
• Use middleware to enforce a maximum query string size or parameter count, or
• Employ a reverse proxy (such as Nginx) to limit request sizes and reject oversized query strings or bodies.

Limiting request body sizes and query string lengths at the web server or CDN level is an effective mitigation.

Release Notes

3.2.2 (from changelog)

Security

• CVE-2025-61772 Multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)
• CVE-2025-61771 Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)
• CVE-2025-61770 Unbounded multipart preamble buffering enables DoS (memory exhaustion)

3.2.0 (from changelog)

This release continues Rack's evolution toward a cleaner, more efficient foundation while maintaining backward compatibility for most applications. The breaking changes primarily affect deprecated functionality, so most users should experience a smooth upgrade with improved performance and standards compliance.

SPEC Changes

• Request environment keys must now be strings. (#2310, @jeremyevans)
• Add nil as a valid return from a Response body.to_path (#2318, [@MSP-Greg])
• Rack::Lint#check_header_value is relaxed, only disallowing CR/LF/NUL characters. (#2354, @ioquatix)

Added

• Introduce Rack::VERSION constant. (#2199, @ioquatix)
• ISO-2022-JP encoded parts within MIME Multipart sections of an HTTP request body will now be converted to UTF-8. (#2245, @nappa)
• Add Rack::Request#query_parser= to allow setting the query parser to use. (#2349, @jeremyevans)
• Add Rack::Request#form_pairs to access form data as raw key-value pairs, preserving duplicate keys. (#2351, @matthewd)

Changed

• Invalid cookie keys will now raise an error. (#2193, @ioquatix)
• Rack::MediaType#params now handles empty strings. (#2229, @jeremyevans)
• Avoid unnecessary calls to the ip_filter lambda to evaluate Request#ip (#2287, [@willbryant])
• Only calculate Request#ip once per request (#2292, [@willbryant])
• Rack::Builder #use, #map, and #run methods now return nil. (#2355, @ioquatix)
• Directly close the body in Rack::ConditionalGet when the response is 304 Not Modified. (#2353, @ioquatix)
• Directly close the body in Rack::Head when the request method is HEAD(#2360, @skipkayhil)

Deprecated

• Rack::Auth::AbstractRequest#request is deprecated without replacement. (#2229, @jeremyevans)
• Rack::Request#parse_multipart (private method designed to be overridden in subclasses) is deprecated without replacement. (#2229, @jeremyevans)

Removed

• Rack::Request#values_at is removed. (#2200, @ioquatix)
• Rack::Logger is removed with no replacement. (#2196, @ioquatix)
• Automatic cache invalidation in Rack::Request#{GET,POST} has been removed. (#2230, @jeremyevans)
• Support for CGI::Cookie has been removed. (#2332, @ioquatix)

Fixed

• Rack::RewindableInput::Middleware no longer wraps a nil input. (#2259, @tt)
• Fix NoMethodError in Rack::Request#wrap_ipv6 when x-forwarded-host is empty. (#2270, @oieioi)
• Fix the specification for SERVER_PORT which was incorrectly documented as required to be an Integer if present - it must be a String containing digits only. (#2296, @ioquatix)
• SERVER_NAME and HTTP_HOST are now more strictly validated according to the relevant specifications. (#2298, @ioquatix)
• Rack::Lint now disallows PATH_INFO="" SCRIPT_NAME="". (#2298, @jeremyevans)

3.1.17 (from changelog)

Security

• CVE-2025-61772 Multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)
• CVE-2025-61771 Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)
• CVE-2025-61770 Unbounded multipart preamble buffering enables DoS (memory exhaustion)

3.1.15 (from changelog)

• Optional support for CGI::Cookie if not available. (#2327, #2333, @earlopain)

3.1.14 (from changelog)

Security

• CVE-2025-46727 Unbounded parameter parsing in Rack::QueryParser can lead to memory exhaustion.

3.1.13 (from changelog)

• Ensure Rack::ETag correctly updates response body. (#2324, @ioquatix)

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)

[depfu]

Closed in favor of #391.

[depfu]

Closed in favor of #391.