Updated advisory posts against rubysec/ruby-advisory-db@e80dfb0

Author: jasnow

advisories/_posts/2025-10-07-CVE-2025-61770.md

@@ -0,0 +1,68 @@
+---
+layout: advisory
+title: 'CVE-2025-61770 (rack): Rack''s unbounded multipart preamble buffering enables
+  DoS (memory exhaustion)'
+comments: false
+categories:
+- rack
+advisory:
+  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
+---

advisories/_posts/2025-10-07-CVE-2025-61771.md

@@ -0,0 +1,68 @@
+---
+layout: advisory
+title: 'CVE-2025-61771 (rack): Multipart parser buffers large non‑file fields entirely
+  in memory, enabling DoS (memory exhaustion)'
+comments: false
+categories:
+- rack
+advisory:
+  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
+---

advisories/_posts/2025-10-07-CVE-2025-61772.md

@@ -0,0 +1,67 @@
+---
+layout: advisory
+title: 'CVE-2025-61772 (rack): Rack''s multipart parser buffers unbounded per-part
+  headers, enabling DoS (memory exhaustion)'
+comments: false
+categories:
+- rack
+advisory:
+  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
+---