Answer in brief
CVE-2025-61919 records a High severity (CVSS 7.5) vulnerability in Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing. The current sources do not mark it as known exploited. The current feed maps rack (rubygems), rack (rubygems), rack (rubygems). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps rack (rubygems), rack (rubygems), rack (rubygems). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| rackrubygems | >=0 <2.2.20 | 2.2.20 |
| rackrubygems | >=3.0 <3.1.18 | 3.1.18 |
| rackrubygems | >=3.2 <3.2.3 | 3.2.3 |
Published upstream
Oct 10, 2025
Evidence: source:osv:source_dates:source-dates:recordSource modified
Sep 10, 2026
Evidence: source:osv:source_dates:source-dates:recordFirst seen by HOL
Aug 7, 2026
## Summary `Rack::Request#POST` reads the entire request body into memory for `Content-Type: application/x-www-form-urlencoded`, calling `rack.input.read(nil)` without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion. ## Details When handling non-multipart form submissions, Rack’s request parser performs: ```ruby form_vars = get_header(RACK_INPUT).read ``` Since `read` is called with no argument, the entire request body is loaded into a Ruby `String`. This occurs before query parameter parsing or enforcement of any `params_limit`. As a result, Rack applications without an upstream body-size limit can experience unbounded memory allocation proportional to request size. ## Impact Attackers can send large `application/x-www-form-urlencoded` bodies to consume process memory, causing slowdowns or termination by the operating system (OOM). The effect scales linearly with request size and concurrency. Even with parsing limits configured, the issue occurs *before* those limits are enforced. ## Mitigation * Update to a patched version of Rack that enforces form parameter limits using `query_parser.bytesize_limit`, preventing unbounded reads of `application/x-www-form-urlencoded` bodies. * Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).
Quoted source text, attributed separately from HOL analysis.