Rack
CVE-2025-61919
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach HTTP endpoint using Rack
-
DeliverySend large url-encoded POST body
-
ExploitRack reads entire body unbounded
-
ExecutionProcess memory exhausted (OOM)
-
ImpactWorker crash / service denial
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitable whenever a Rack-based application (versions < 2.2.20, >= 3.0 and < 3.1.18, or >= 3.2 and < 3.2.3) invokes |
| Impact | All signals align on a moderate-to-serious availability-only risk. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, score 7.5) is internally consistent with the description: a remote, unauthenticated attacker can trigger the flaw over the network with low complexity and no user interaction, but impact is confined to availability (C:N/I:N) via memory exhaustion (CWE-400), so this is a pure DoS, not an RCE or data-exposure issue. No EPSS score, no CISA KEV listing, and no weaponized public exploit were provided in the input - the only 'exploit' artifacts are the vendor's own patch commits and regression tests, which demonstrate the mechanism but are not attack tooling. Per precision rules this is therefore 'no public exploit identified at time of analysis', and must NOT be conflated with active exploitation. The practical risk is real but conditional: exploitation is trivial to perform yet the full severity only materializes for Rack deployments that lack an upstream body-size cap, since the unbounded read happens before Rack's own param limits are enforced. Net: treat as a prioritized patch for internet-facing Ruby web applications, but recognize that defenders with proxy-level body limits already have substantial mitigation, which lowers real-world impact below what the raw 7.5 might suggest. |
| Exploit ScenarioDerived | An unauthenticated attacker sends one or more large |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Rack before 2.2.20, 3.1.x before 3.1.18, and 3.2.x before 3.2.3 allows remote unauthenticated memory-exhaustion denial of service when an application parses an application/x-www-form-urlencoded POST body through Rack::Request#POST. The parser calls rack.input.read(nil), buffering the entire body into a Ruby String before parameter or byte-size limits are enforced, so large or concurrent requests can drive process memory consumption and potentially trigger OOM termination. No public exploit code was identified at the time of analysis, and the primary exposure is limited to deployments that invoke the affected parsing path without an upstream body-size cap such as Nginx client_max_body_size or Apache LimitRequestBody.
RemediationAI
Upgrade Rack to 2.2.20, 3.1.18, or 3.2.3 depending on the maintained branch; these releases enforce form parameter limits through query_parser.bytesize_limit and bound the read of application/x-www-form-urlencoded bodies. In addition, enforce strict maximum request body sizes at the proxy or web server layer, such as Nginx client_max_body_size or Apache LimitRequestBody, which bounds memory allocation even for unpatched deployments; tune these limits to the largest legitimate form submission because overly small values will reject valid requests. Review the vendor advisory at https://github.com/rack/rack/security/advisories/GHSA-6xw4-3v39-52mm and the referenced patch commits for the exact changes. Where an upstream body-size limit is already enforced, exposure is materially reduced, but patching remains the direct fix.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in rubygems
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The issue is a CWE-400 uncontrolled resource consumption flaw in Rack's request form parsing. In lib/rack/request.rb, the POST method handles non-multipart form submissions by calling get_header(RACK_INPUT).read with no length argument, which asks the Rack input object for the entire request body and allocates a Ruby String proportional to its size. Because this occurs before query parameter parsing and before any configured params_limit or query_parser.bytesize_limit is applied, an attacker can force unbounded allocation for Content-Type: application/x-www-form-urlencoded requests. The upstream fix changes this to read query_parser.bytesize_limit + 2 bytes and handle nil, exposing bytesize_limit as an attr_reader in lib/rack/query_parser.rb so form parsing is bounded before allocation. The affected CPE entries identify the Ruby rack package, and the patch commits are 4e2c903991a790ee211a3021808ff4fd6fe82881 and cbd541e8a3d0c5830a3c9a30d3718ce2e124f9db, with the GitHub security advisory GHSA-6xw4-3v39-52mm describing the same root cause.
Know when Rack gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Remote, low-complexity, unauthenticated (PR:N) url-encoded POST triggers memory exhaustion; impact is availability-only, so C:N/I:N/A:H with unchanged scope.
Primary rating from Vendor (github).
CVSS VectorVendor: github
DescriptionCVE.org
Rack is a modular Ruby web server interface. Prior to versions 2.2.20, 3.1.18, and 3.2.3, 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. Users should upgrade to Rack version 2.2.20, 3.1.18, or 3.2.3, anu of which enforces form parameter limits using query_parser.bytesize_limit, preventing unbounded reads of application/x-www-form-urlencoded bodies. Additionally, enforce strict maximum body size at the proxy or web server layer (e.g., Nginx client_max_body_size, Apache LimitRequestBody).
Executive ViewAI
Rack, a widely used Ruby web server interface, has a high-severity memory-exhaustion denial-of-service issue that can cause process termination and service outages when affected applications process large form-encoded POST bodies. Internet-facing Ruby applications running affected Rack versions are most exposed, especially where no upstream request-size limit is enforced. No public exploit identified at time of analysis, but the availability risk and available fix warrant prompt action.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Affected Products (CPE)CVE.org
Directory traversal in Rack versions prior to 2.2.22, 3.1.20, and 3.2.5 allows unauthenticated remote attackers to list
Rack is a modular Ruby web server interface. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable,
Rack is a modular Ruby web server interface. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable,
A reliance on cookies without validation/integrity check security vulnerability exists in rack < 2.2.3, rack < 2.1.4 tha
A sequence injection vulnerability exists in Rack <2.0.9.1, <2.1.4.1 and <2.2.3.1 which could allow is a possible shell
Rack provides an interface for developing web applications in Ruby. Rated medium severity (CVSS 5.7), this vulnerability
Rack's Directory module fails to sanitize filenames when generating HTML directory listings, allowing attackers to craft
Session authentication bypass in Rack::Session::Cookie 2.0.0 through 2.1.1 allows unauthenticated remote attackers to fo
A directory traversal vulnerability exists in rack < 2.2.0 that allows an attacker perform directory traversal vulnerabi
Rack::Session::Cookie in Rack 1.5.x before 1.5.2, 1.4.x before 1.4.5, 1.3.x before 1.3.10, 1.2.x before 1.2.8, and 1.1.x
A DoS vulnerability exists in Rack <v3.0.4.2, <v2.2.6.3, <v2.1.4.3 and <v2.0.9.3 within in the Multipart MIME parsing co
Memory exhaustion denial of service in the Ruby Rack web server interface (versions prior to 2.2.19, 3.1.17, and 3.2.2)
Exploit-DB