CVE-2025-61919
BaseFortify
Publication date: 2025-10-10
Last updated on: 2025-11-03
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.20 (exc) |
| rack | rack | From 3.0.0 (inc) to 3.1.18 (exc) |
| rack | rack | From 3.2.0 (inc) to 3.2.3 (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 the method Rack::Request#POST reads the entire request body into memory for requests with Content-Type: application/x-www-form-urlencoded without enforcing any length limit. This means that very large request bodies can be fully loaded into memory, potentially exhausting system memory and causing a denial of service (DoS).
How can this vulnerability impact me? :
The vulnerability can lead to denial of service (DoS) by exhausting the server's memory when processing large request bodies. This can cause the server to become unresponsive or crash, disrupting service availability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection can involve monitoring for unusually large HTTP POST requests with Content-Type: application/x-www-form-urlencoded that may cause memory exhaustion. Commands to inspect such requests depend on your environment; for example, using network packet capture tools like tcpdump or Wireshark to filter POST requests, or checking web server logs for large request bodies. However, specific commands are not provided in the available information.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading Rack to version 2.2.20, 3.1.18, or 3.2.3 or later, which enforce form parameter limits to prevent unbounded reads. Additionally, configure your proxy or web server to enforce strict maximum body size limits, such as setting 'client_max_body_size' in Nginx or 'LimitRequestBody' in Apache.