CVE-2025-61771: Rack's multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)

Published Oct 7, 2025
·
Updated

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 @mimeparts[mimeindex].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 clientmaxbodysize). Validate and reject unusually large form fields at the application level.

Other sources

Rack is a modular Ruby web server interface. In versions prior to 2.2.19, 3.1.17, and 3.2.2, 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). 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. Versions 2.2.19, 3.1.17, and 3.2.2 enforce a reasonable size cap for non-file fields (e.g., 2 MiB). Workarounds include restricting maximum request body size at the web-server or proxy layer (e.g., Nginx clientmaxbodysize) and validating and rejecting unusually large form fields at the application level.

MITRE

Affected Software

8 affected componentsFixes available
Rack Rack<2.2.19, <3.1.17, <3.2.2
Rack Rack Ruby<2.2.19
Rack Rack Ruby>=3.1.0<3.1.17
Rack Rack Ruby>=3.2.0<3.2.2
rubygems/rack>=3.2<3.2.2
3.2.2
rubygems/rack>=3.1<3.1.17
3.1.17
rubygems/rack<2.2.19
2.2.19
IBM Aspera Console<=3.4.7

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade rubygems/rack to a version that resolves this vulnerability.

    Fixed in 3.2.2
  2. Upgrade

    Upgrade rubygems/rack to a version that resolves this vulnerability.

    Fixed in 3.1.17
  3. Upgrade

    Upgrade rubygems/rack to a version that resolves this vulnerability.

    Fixed in 2.2.19
  4. Upgrade

    Upgrade Rack to a version that resolves this vulnerability.

    Fixed in 2.2.19
  5. Upgrade

    Upgrade Rack to a version that resolves this vulnerability.

    Fixed in 3.1.17
  6. Upgrade

    Upgrade Rack to a version that resolves this vulnerability.

    Fixed in 3.2.2
  7. Configuration

    At the web-server/proxy layer, restrict the maximum request body size using Nginx `client_max_body_size` to limit multipart payloads that could otherwise exhaust memory in Rack.

    Nginx client_max_body_size = (set to an appropriate maximum smaller than what would cause OOM; workaround example provided)
  8. Configuration

    At the application level, validate and reject unusually large non-file multipart form fields (parts without a `filename`) before they are accepted/processed to prevent in-RAM buffering from causing OOM/DoS.

    Rack application (multipart/form-data handling) application-level non-file form field size validation = (reject unusually large form fields)

Event History

Oct 7, 2025
CVE Published
via MITRE·02:42 PM
Data Sourced
via MITRE·02:42 PM
DescriptionSeverityWeakness
Data Sourced
via Red Hat·03:01 PM
DescriptionSeverityAffected Software
Data Sourced
via NVD·03:16 PM
RemedyDescriptionSeverityWeaknessAffected Software
Advisory Published
via GitHub·05:27 PM
Data Sourced
via GitHub·05:27 PM
DescriptionSeverityWeaknessAffected Software
Jan 8, 2026
Data Sourced
via IBM·12:00 AM
DescriptionAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Frequently Asked Questions

1

What is the severity of CVE-2025-61771?

CVE-2025-61771 has a moderate severity level due to the potential risk of excessive memory usage from unbounded large text fields.

2

How do I fix CVE-2025-61771?

To fix CVE-2025-61771, upgrade Rack to version 2.2.19, 3.1.17, or 3.2.2 or later.

3

What versions of Rack are affected by CVE-2025-61771?

CVE-2025-61771 affects Rack versions prior to 2.2.19, 3.1.17, and 3.2.2.

4

What type of data does CVE-2025-61771 impact?

CVE-2025-61771 impacts non-file form fields in multipart/form-data requests stored in memory.

5

What is the potential exploit of CVE-2025-61771?

The potential exploit of CVE-2025-61771 lies in the denial of service through excessive memory consumption.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203