Rack
CVE-2025-61771
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify Rack endpoint accepting multipart forms
-
DeliveryCraft multipart request with huge non-file field
-
ExploitSubmit concurrent oversized requests
-
ExecutionWorker memory buffers unbounded
-
ImpactOOM crash / GC thrashing denies service
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 against any Rack application that parses multipart/form-data submissions (the default for file-upload and form endpoints) - the advisory states all such applications are affected, so no special feature toggle is required. The specific prerequisite is an endpoint that invokes Rack::Multipart parsing and accepts a non-file form part (a part without a 'filename'). Limiting factors: exploitation is effectively neutralized where an upstream web server or proxy enforces a maximum request body size (e.g. Nginx client_max_body_size) or where the application validates/rejects oversized fields; impact also scales with concurrency and available worker memory, so hardened deployments with strict body caps are not practically exposed. |
| Impact | This is a genuine but moderate-priority availability issue, not a top-tier emergency. The CVSS 7.5 is driven entirely by the availability impact (A:H) of a network-reachable, low-complexity, unauthenticated vector (AV:N/AC:L/PR:N/UI:N) with no confidentiality or integrity impact (C:N/I:N) - consistent with CWE-400 resource exhaustion. The signals are internally coherent: EPSS is low (0.56%, 46th percentile), there is no CISA KEV listing and no public exploit identified at time of analysis, so there is no evidence of active exploitation or weaponized tooling. The attack is conceptually trivial (send a huge non-file multipart field), which keeps attack complexity low, but real-world impact depends heavily on the absence of upstream body-size limits - many production deployments already sit behind a reverse proxy with a request-size cap, which blunts exploitability. There are no conflicting signals here (the description's 'remote, large request' model matches AV:N/A:H cleanly). Net: a real DoS worth patching on a normal maintenance cadence, but the low EPSS and lack of exploitation evidence argue against treating it as an urgent, actively-targeted threat. |
| Exploit ScenarioDerived | An unauthenticated remote attacker submits a multipart/form-data POST to any Rack-backed endpoint (e.g. a Rails or Sinatra form handler) containing a single non-file text field of several hundred megabytes. Rack buffers that field entirely in memory as a Ruby String, and repeating the request across concurrent connections exhausts worker process memory, causing OOM kills, worker crashes, or crippling garbage-collection overhead. No public exploit is identified, but the technique is trivial to reproduce and requires only a standard HTTP client. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Rack's multipart/form-data parser prior to 2.2.19, 3.1.17, and 3.2.2 buffers every non-file form field entirely in process memory as a Ruby String with no size cap, so a single request carrying a very large text part can drive worker memory consumption to hundreds of megabytes or more. Remote, unauthenticated attackers (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) can exploit this against any Rack application that parses multipart submissions, causing out-of-memory kills, worker crashes, or severe garbage-collection thrash; impact scales with request size and concurrency. No public exploit code and no confirmed active exploitation were identified at time of analysis, and EPSS is modest at 0.56% (46th percentile), so this is a genuine but moderate-priority availability issue rather than a top-tier emergency - especially where a reverse proxy already enforces a body-size limit.
RemediationAI
Vendor-released patch: upgrade to Rack 2.2.19, 3.1.17, or 3.2.2 (all released 2025-10-07), which enforce an approximately 2 MiB cap on non-file multipart fields; fixes are in commits 589127f4ac8b5cf11cf88fb0cd116ffed4d2181e and d869fed663b113b95a74ad53e1b5cae6ab31f29e, and the advisory at https://github.com/rack/rack/security/advisories/GHSA-w9pc-fmgc-vxvw lists the exact version boundaries. If an immediate upgrade is not possible, cap the request body at the edge - Nginx client_max_body_size (or the equivalent limit in HAProxy, Envoy, or the Rails/Rack front controller) - accepting the trade-off that legitimate large uploads must then be handled through a separate larger-limit route or chunked upload flow. Alternatively, validate and reject unusually large form fields at the application level before they are materialized into params, which requires per-endpoint code changes and can break legitimate long-text submissions if the threshold is set too low. Deployments that already enforce a strict proxy-level body cap are largely neutralized, but patching remains the durable fix because it bounds memory per field rather than per request.
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
Rack is the modular Ruby web server interface that sits beneath Rails, Sinatra, and most Ruby web frameworks, and Rack::Multipart::Parser is the component that decodes multipart/form-data submissions. Its design streams file parts (parts carrying a filename) to temporary files on disk, but non-file parts - ordinary text fields - are accumulated into an in-memory buffer (body = String.new; @mime_parts[mime_index].body << content) that has no upper bound. This is CWE-400 (Uncontrolled Resource Consumption): the parser trusts caller-supplied part sizes when allocating heap, so a single multi-hundred-megabyte text field is materialized in full before it ever reaches params. The upstream fix caps non-file fields at roughly 2 MiB and, in the same release series, adds related parser guardrails - a 16 KiB BOUNDARY_START_LIMIT and a 64 KiB MIME_HEADER_BYTESIZE_LIMIT - that address sibling issues CVE-2025-61770 (unbounded preamble buffering) and CVE-2025-61772 (unbounded per-part headers). CPE data identifies the affected package simply as rack:rack for the Ruby ecosystem; the practical exposure is the entire downstream ecosystem of Ruby applications exposing form or upload endpoints.
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 unauthenticated POST with no user interaction (AV:N/AC:L/PR:N/UI:N); pure memory-exhaustion DoS yields A:H with no confidentiality or integrity impact.
Primary rating from Vendor (github).
CVSS VectorVendor: github
DescriptionCVE.org
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 client_max_body_size) and validating and rejecting unusually large form fields at the application level.
Executive ViewAI
Rack's multipart/form-data parser, used across Ruby web applications, can be forced to consume hundreds of megabytes of memory per request by a remote unauthenticated attacker, leading to worker crashes and service disruption. Leadership should care because any internet-facing Rack application that accepts multipart uploads is exposed to availability loss, though risk is reduced where reverse proxies enforce body-size limits.
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