Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions gems/rack/CVE-2025-61770.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
---
gem: rack
cve: 2025-61770
ghsa: p543-xpfm-54cp
url: https://github.com/rack/rack/security/advisories/GHSA-p543-xpfm-54cp
title: Rack's unbounded multipart preamble buffering enables
DoS (memory exhaustion)
date: 2025-10-07
description: |
## Summary

`Rack::Multipart::Parser` buffers the entire multipart **preamble**
(bytes before the first boundary) in memory without any size limit.
A client can send a large preamble followed by a valid boundary,
causing significant memory use and potential process termination
due to out-of-memory (OOM) conditions.

## Details

While searching for the first boundary, the parser appends incoming
data into a shared buffer (`@sbuf.concat(content)`) and scans for
the boundary pattern:

```ruby
@sbuf.scan_until(@body_regex)
```

If the boundary is not yet found, the parser continues buffering
data indefinitely. There is no trimming or size cap on the preamble,
allowing attackers to send arbitrary amounts of data before the
first boundary.

## Impact

Remote attackers can trigger large transient memory spikes by
including a long preamble in multipart/form-data requests. The
impact scales with allowed request sizes and concurrency, potentially
causing worker crashes or severe slowdown due to garbage collection.

## Mitigation

* **Upgrade:** Use a patched version of Rack that enforces a preamble
size limit (e.g., 16 KiB) or discards preamble data entirely per
[RFC 2046 § 5.1.1](https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1.1).

* **Workarounds:**
* Limit total request body size at the proxy or web server level.
* Monitor memory and set per-process limits to prevent OOM conditions.
cvss_v3: 7.5
patched_versions:
- "~> 2.2.19"
- "~> 3.1.17"
- ">= 3.2.2"
related:
url:
- https://nvd.nist.gov/vuln/detail/CVE-2025-61770
- https://github.com/rack/rack/security/advisories/GHSA-p543-xpfm-54cp
- https://github.com/rack/rack/commit/589127f4ac8b5cf11cf88fb0cd116ffed4d2181e
- https://github.com/rack/rack/commit/d869fed663b113b95a74ad53e1b5cae6ab31f29e
- https://github.com/rack/rack/commit/e08f78c656c9394d6737c022bde087e0f33336fd
- https://github.com/advisories/GHSA-p543-xpfm-54cp
60 changes: 60 additions & 0 deletions gems/rack/CVE-2025-61771.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
---
gem: rack
cve: 2025-61771
ghsa: w9pc-fmgc-vxvw
url: https://github.com/rack/rack/security/advisories/GHSA-w9pc-fmgc-vxvw
title: Multipart parser buffers large non‑file fields
entirely in memory, enabling DoS (memory exhaustion)
date: 2025-10-07
description: |
## Summary

`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).

## Details

During multipart parsing, file parts are streamed to temporary files,
but non-file parts are buffered into memory:

```ruby
body = String.new # non-file → in-RAM buffer
@mime_parts[mime_index].body << content
```

There is no size limit on these in-memory buffers. As a result, any
large text field—while technically valid—will be loaded fully into
process memory before being added to `params`.

## Impact

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.

## Mitigation

* **Upgrade:** Use a patched version of Rack that enforces a
reasonable size cap for non-file fields (e.g., 2 MiB).

* **Workarounds:**
* Restrict maximum request body size at the web-server or proxy
layer (e.g., Nginx `client_max_body_size`).
* Validate and reject unusually large form fields at the application level.
cvss_v3: 7.5
patched_versions:
- "~> 2.2.19"
- "~> 3.1.17"
- ">= 3.2.2"
related:
url:
- https://nvd.nist.gov/vuln/detail/CVE-2025-61771
- https://github.com/rack/rack/security/advisories/GHSA-w9pc-fmgc-vxvw
- https://github.com/rack/rack/commit/589127f4ac8b5cf11cf88fb0cd116ffed4d2181e
- https://github.com/rack/rack/commit/d869fed663b113b95a74ad53e1b5cae6ab31f29e
- https://github.com/rack/rack/commit/e08f78c656c9394d6737c022bde087e0f33336fd
- https://github.com/advisories/GHSA-w9pc-fmgc-vxvw
59 changes: 59 additions & 0 deletions gems/rack/CVE-2025-61772.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
---
gem: rack
cve: 2025-61772
ghsa: wpv5-97wm-hp9c
url: https://github.com/rack/rack/security/advisories/GHSA-wpv5-97wm-hp9c
title: Rack's multipart parser buffers unbounded per-part headers,
enabling DoS (memory exhaustion)
date: 2025-10-07
description: |
## Summary

`Rack::Multipart::Parser` can accumulate unbounded data when a
multipart part’s header block never terminates with the required
blank line (`CRLFCRLF`). The parser keeps appending incoming bytes
to memory without a size cap, allowing a remote attacker to exhaust
memory and cause a denial of service (DoS).

## Details

While reading multipart headers, the parser waits for `CRLFCRLF` using:

```ruby
@sbuf.scan_until(/(.*?\r
)\r
/m)
```

If the terminator never appears, it continues appending data
(`@sbuf.concat(content)`) indefinitely. There is no limit on
accumulated header bytes, so a single malformed part can consume
memory proportional to the request body size.

## Impact

Attackers can send incomplete multipart headers to trigger high memory
use, leading to process termination (OOM) or severe slowdown. The
effect scales with request size limits and concurrency. All
applications handling multipart uploads may be affected.

## Mitigation

* Upgrade to a patched Rack version that caps per-part header size
(e.g., 64 KiB).

* Until then, restrict maximum request sizes at the proxy or web
server layer (e.g., Nginx `client_max_body_size`).
cvss_v3: 7.5
patched_versions:
- "~> 2.2.19"
- "~> 3.1.17"
- ">= 3.2.2"
related:
url:
- https://nvd.nist.gov/vuln/detail/CVE-2025-61772
- https://github.com/rack/rack/security/advisories/GHSA-wpv5-97wm-hp9c
- https://github.com/rack/rack/commit/589127f4ac8b5cf11cf88fb0cd116ffed4d2181e
- https://github.com/rack/rack/commit/d869fed663b113b95a74ad53e1b5cae6ab31f29e
- https://github.com/rack/rack/commit/e08f78c656c9394d6737c022bde087e0f33336fd
- https://github.com/advisories/GHSA-wpv5-97wm-hp9c