# Specially constructed multi-part requests cause multi-second response times; vulnerable to DoS

Rack/Rails multipart parsing scales worse than linearly with part count, so a 10,000-part body ties up a request for 15-25 seconds, enabling DoS.

- Payout: hidden
- Severity: medium
- Program: Ruby on Rails
- Found by: bjeanes
- Disclosed: 2018-12-05
- CVE: CVE-2018-16470
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/431561
- Library page: https://bugbountylibrary.com/r/h1%3A431561
- Tags: area:web domain:web impact:dos kind:bounty platform:hackerone sev:medium tech:ruby technique:source-review vuln:dos

**Target:** Rack multipart body parser in Rails request handling
**Root cause:** Multipart body parsing performance degrades worse-than-linearly with the number of parts in the request body, so parsing cost grows superlinearly.
**Steps:**
1. Generate a multipart request body with ~10,000 parts using the provided gist script against any Rack-based app.
2. Send the request; once transfer completes, the server spends 15-25 seconds servicing it (observed on GitHub API).
3. Scale part count (20,000 parts ~25s per benchmark) or send many such requests to exhaust web serving resources.
**How found:** Benchmarked Rack multipart parsing across increasing part counts (N=1 to 20,000), observing superlinear time growth, then validated against live Rails apps including GitHub, Heroku API, Instacart, Shopify and Bugcrowd.
**Exploitation:** Attacker submits a specially constructed multipart request (constructible from a plain HTML form) with thousands of parts; each request occupies a worker for many seconds, and enough requests starve request servicing, causing gateway timeouts.
**Escalation:** Combined with XSS or another mechanism, arbitrary user agents could be made en masse to send such requests.
**Insight:** Benchmark parser cost as a function of attacker-controlled element counts (parts, fields, nesting) rather than payload size; multipart part count is a cheap DoS lever even when total bytes are small.