CVE-2025-61771
BaseFortify
Publication date: 2025-10-07
Last updated on: 2025-10-10
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| rack | rack | to 2.2.19 (exc) |
| rack | rack | From 3.1.0 (inc) to 3.1.17 (exc) |
| rack | rack | From 3.2.0 (inc) to 3.2.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-400 | The product does not properly control the allocation and maintenance of a limited resource. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the Rack Ruby web server interface where non-file form fields in multipart/form-data requests are stored entirely in memory as Ruby String objects. If an attacker sends a very large text field (hundreds of megabytes or more), it can consume a large amount of process memory, potentially causing out-of-memory conditions and denial of service by crashing workers or causing severe garbage collection overhead. This affects all Rack applications processing multipart form submissions in versions prior to 2.2.19, 3.1.17, and 3.2.2.
How can this vulnerability impact me? :
The vulnerability can lead to denial of service (DoS) by exhausting server memory when processing large non-file form fields in multipart requests. This can cause worker crashes or severe performance degradation due to garbage collection overhead, impacting availability of the affected Rack-based web applications.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for unusually large multipart/form-data requests containing large non-file fields that consume excessive memory. Since the vulnerability involves large text fields causing high memory usage, you can detect it by inspecting web server logs for large request sizes or by using network monitoring tools to identify large POST requests. Commands to check request sizes in logs or monitor memory usage of Rack application processes may help. However, no specific commands are provided in the available information.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading Rack to versions 2.2.19, 3.1.17, or 3.2.2 or later, which enforce a reasonable size cap (e.g., 2 MiB) for non-file fields. Additionally, you can restrict the maximum request body size at the web-server or proxy layer, for example by setting Nginx's 'client_max_body_size' directive to limit request sizes. Validating and rejecting unusually large form fields at the application level is also recommended to prevent excessive memory consumption.