Answer in brief
CVE-2026-34829 records a High severity (CVSS 7.5) vulnerability in Rack: Denial of Service via Unbounded Multipart File Upload Without Content-Length. The current sources do not mark it as known exploited. The current feed maps rack/rack (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps rack/rack (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| rack/rackgeneric | < 2.2.23 || >= 3.0.0.beta1, < 3.1.21 || >= 3.2.0, < 3.2.6 | Not reported |
Published upstream
Apr 2, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jul 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 15, 2026
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Multipart::Parser only wraps the request body in a BoundedIO when CONTENT_LENGTH is present. When a multipart/form-data request is sent without a Content-Length header, such as with HTTP chunked transfer encoding, multipart parsing continues until end-of-stream with no total size limit. For file parts, the uploaded body is written directly to a temporary file on disk rather than being constrained by the buffered in-memory upload limit. An unauthenticated attacker can therefore stream an arbitrarily large multipart file upload and consume unbounded disk space. This results in a denial of service condition for Rack applications that accept multipart form data. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-34829 records a High severity (CVSS 7.5) vulnerability in Rack: Denial of Service via Unbounded Multipart File Upload Without Content-Length. The current sources do not mark it as known exploited. The current feed maps rack/rack (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps rack/rack (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| rack/rackgeneric | < 2.2.23 || >= 3.0.0.beta1, < 3.1.21 || >= 3.2.0, < 3.2.6 | Not reported |
Published upstream
Apr 2, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jul 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 15, 2026
Rack is a modular Ruby web server interface. Prior to versions 2.2.23, 3.1.21, and 3.2.6, Rack::Multipart::Parser only wraps the request body in a BoundedIO when CONTENT_LENGTH is present. When a multipart/form-data request is sent without a Content-Length header, such as with HTTP chunked transfer encoding, multipart parsing continues until end-of-stream with no total size limit. For file parts, the uploaded body is written directly to a temporary file on disk rather than being constrained by the buffered in-memory upload limit. An unauthenticated attacker can therefore stream an arbitrarily large multipart file upload and consume unbounded disk space. This results in a denial of service condition for Rack applications that accept multipart form data. This issue has been patched in versions 2.2.23, 3.1.21, and 3.2.6.
Quoted source text, attributed separately from HOL analysis.