diff --git a/gems/rack/CVE-2025-61770.yml b/gems/rack/CVE-2025-61770.yml
new file mode 100644
index 0000000000..e18a526a58
--- /dev/null
+++ b/gems/rack/CVE-2025-61770.yml
@@ -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
diff --git a/gems/rack/CVE-2025-61771.yml b/gems/rack/CVE-2025-61771.yml
new file mode 100644
index 0000000000..1341ad578e
--- /dev/null
+++ b/gems/rack/CVE-2025-61771.yml
@@ -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
diff --git a/gems/rack/CVE-2025-61772.yml b/gems/rack/CVE-2025-61772.yml
new file mode 100644
index 0000000000..8bff65ad60
--- /dev/null
+++ b/gems/rack/CVE-2025-61772.yml
@@ -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