Rack: Multipart parsing allows DoS via unbounded scan buffer growth
Severity and exploitation
KEV coverage does not rule out exploitation.
Assessment vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HAssessment vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NAssessment vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HSeverity
high7.5CVSS measures technical severity, not the likelihood of an attack.
Known exploitation
Not listed in the checked CISA KEV catalog
Absence from CISA KEV does not rule out attacks.
Public exploit
Not established by this record
Missing evidence does not mean no public exploit exists.
Remediation
Package fixes recorded
Fix versions are recorded for 1 of 1 mapped packages. Check each release branch and any separate product guidance.
What this means
Rack::Multipart::Parser reads the request body in chunks of rack.multipart.buffer_size (1 MiB by default) into an internal scan buffer. Parsed bytes are only discarded from that buffer when a chunk ends inside a part body. A request whose parts are sized so that every chunk ends inside, or immediately after, a part's headers is never compacted, so the buffer grows to the size of the request.
Source excerpt · OSVAttack conditions
The attack requires only a well-formed multipart body.
Excerpt from the original source description below.
Review supporting sources →Affected versions
Check the exact model, release, and any platform requirements against your installation.
rack · GitHub_M
rack
3 ranges
rack · GitHub_M
rack
Compare with this publisher’s ranges. This does not inspect your installation.
affected
< 2.2.25
>= 3.0, < 3.1.23
>= 3.2, < 3.2.8
Other versions: unknown
Packages
Compare each installed version with the publisher’s affected ranges. Where a fix is recorded, choose the appropriate release branch and test compatibility before upgrading.
| Affected range | Recorded fix |
|---|---|
| Earlier releases before 2.2.25Ecosystem versions | 2.2.25 |
| From 3.0.0 before 3.1.23Ecosystem versions | 3.1.23 |
| From 3.2.0 before 3.2.8Ecosystem versions | 3.2.8 |
Version evidence: OSV · GHSA-5v64-555j-wjxm
View original version evidence (179 explicit versions)
What to do
Compare your installed product and version with the affected versions above. A matching product name alone does not confirm exposure.
Use the recorded fix for your release branch. Review the publisher’s instructions and test compatibility before upgrading.
cve.new guidance unless attributed to a publisher. This page does not inspect your installation.
Public exploit evidence
No public exploit reference is identified in the imported evidence. This is not a claim that no exploit exists.
Original source description
Read the full publisher description
Summary
Rack::Multipart::Parser reads the request body in chunks of rack.multipart.buffer_size (1 MiB by default) into an internal scan buffer. Parsed bytes are only discarded from that buffer when a chunk ends inside a part body. A request whose parts are sized so that every chunk ends inside, or immediately after, a part's headers is never compacted, so the buffer grows to the size of the request.
This results in a denial of service condition through memory exhaustion for applications that parse multipart requests.
Details
The parser appends each chunk read from the input to a StringScanner and advances through boundaries, headers, and bodies. In the body state, when no closing boundary is found, the consumed prefix is removed before more data is read. In the header state, and in the body state when no body bytes have been consumed yet, the parser requests more data without removing anything. Bytes skipped between parts are not counted against any limit.
An attacker can therefore construct parts that each fit within one chunk and align the chunk boundaries with the part headers. The existing limits on buffered non-file field data, header size, and preamble size do not apply, because each individual part remains small. With default limits the buffer can reach roughly 4 GiB (4096 parts of about 1 MiB). Ordinary file uploads aligned the same way are bounded by the file part limit at roughly 128 MiB per request.
Impact
Any application that parses multipart requests with Rack is affected in its default configuration. An unauthenticated attacker can cause a single request to hold memory proportional to its size for the duration of parsing, exhausting worker memory. The attack requires only a well-formed multipart body.
Mitigation
- Update to a patched version of Rack in which the parser discards parsed bytes from its scan buffer before reading more data.
- Limit the request body size at a reverse proxy or application boundary.
- Set
RACK_MULTIPART_PARSER_BYTESIZE_LIMITto the largest multipart body the application needs to accept, which bounds the memory a single request can hold.
References
7 sourcesView 1 more references
Inside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-125111View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.
cve.new JSON →Underlying weaknesses
The source’s classification of what caused the vulnerability.
Contributing organizations · 2
Assigning organization
Additional data publisher
Timeline
All times UTCAdvisory published
Publication date supplied by the source.
Source updated
Latest modification date supplied by the source.
Last imported by cve.new
Latest catalog import, not the date we first saw this advisory.
What changed
Follow changes- CVE · CVE-2026-125111
Observed 2026-11-12T19:39:57.803Z · upstream updated 2026-11-12T18:04:38.080Z
Prioritization updated
before
[]
after
[ { "source": "CISA-ADP", "type": "SSVC", "role": "CISA Coordinator", "timestamp": "2026-11-12T16:37:33.895886Z", "decisions": [ { "name": "Exploitation", "value": "none" }, { "name": "Automatable", "value": "yes" }, { "name": "Technical Impact", "value": "partial" } ] } ]
Large field values are marked as truncated previews. Original source snapshots remain retained.
Showing up to 50 most recent observed changes.