NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
💎
💎 RubyGems
Not in CISA KEV
HIGH severity

Rack: Multipart parsing allows DoS via unbounded scan buffer growthGHSA-5v64-555j-wjxm

HIGHFix: rack/rack@244e75a

GHSA-5v64-555j-wjxm is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in rack. A fix is available for rack — see the affected versions and patch details below.

Also known asCVE-2026-125111
Published
Updated
Affected
3 pkgs
Patched
3 / 3
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs31th percentile — riskier than 31% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

3 pkgs affected
💎rack💎rack💎rack

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.

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_LIMIT to the largest multipart body the application needs to accept, which bounds the memory a single request can hold.

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
💎RubyGemsrackall versions2.2.25bundle update rack --conservative
💎RubyGemsrack≥ 3.0.0&&< 3.1.233.1.23bundle update rack --conservative
💎RubyGemsrack≥ 3.2.0&&< 3.2.83.2.8bundle update rack --conservative

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for rack, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update rack to 2.2.25 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5v64-555j-wjxm is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

## 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
O3 Security · Impact-Aware SCA

Is GHSA-5v64-555j-wjxm in your dependencies?

Find it across RubyGems, including transitive dependencies.

Rack: Multipart parsing allows DoS via unbounded scan…