From 1f3ba614671d60ac5265ea6f92b089b481de72a6 Mon Sep 17 00:00:00 2001 From: Al Snow Date: Tue, 7 Oct 2025 09:57:58 -0400 Subject: [PATCH 1/2] 1 brand new advisory --- gems/uri/CVE-2025-61594.yml | 41 +++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 gems/uri/CVE-2025-61594.yml diff --git a/gems/uri/CVE-2025-61594.yml b/gems/uri/CVE-2025-61594.yml new file mode 100644 index 0000000000..e8e2c9cf17 --- /dev/null +++ b/gems/uri/CVE-2025-61594.yml @@ -0,0 +1,41 @@ +--- +gem: uri +cve: 2025-61594 +url: https://www.ruby-lang.org/en/news/2025/10/07/uri-cve-2025-61594 +title: CVE-2025-61594 - URI Credential Leakage Bypass over CVE-2025-27221 +date: 2025-10-07 +description: | + + In affected URI version, a bypass exists for the fix to CVE-2025-27221 + that can expose user credentials. + + This vulnerability has been assigned the CVE identifier CVE-2025-61594. + We recommend upgrading the uri gem. + + ## Details + + When using the + operator to combine URIs, sensitive information + like passwords from the original URI can be leaked, violating + RFC3986 and making applications vulnerable to credential exposure. + + Please update URI gem to version 0.12.5, 0.13.3, 1.0.4 or later. + + ## Affected versions + + uri gem versions < 0.12.5, 0.13.0 to 0.13.2 and 1.0.0 to 1.0.3. + + ## Credits + + Thanks to junfuchong (chongfujun) for discovering this issue. + Also thanks to nobu for additional fixes of this vulnerability. +patched_versions: + - "~> 0.12.5" + - "~> 0.13.3" + - ">= 1.0.4" +related: + url: + - https://www.ruby-lang.org/en/news/2025/10/07/uri-cve-2025-61594 + - https://rubygems.org/gems/uri/versions/1.0.4 + - https://rubygems.org/gems/uri/versions/0.13.3 + - https://rubygems.org/gems/uri/versions/0.12.5 + - https://github.com/ruby/uri From 4a0e8b896c49d69f174ccb62a669a4787f0c3514 Mon Sep 17 00:00:00 2001 From: Al Snow Date: Wed, 8 Oct 2025 11:11:36 -0400 Subject: [PATCH 2/2] GHSA SYNC: 3 brand new advisories --- gems/rack/CVE-2025-61770.yml | 61 ++++++++++++++++++++++++++++++++++++ gems/rack/CVE-2025-61771.yml | 60 +++++++++++++++++++++++++++++++++++ gems/rack/CVE-2025-61772.yml | 59 ++++++++++++++++++++++++++++++++++ 3 files changed, 180 insertions(+) create mode 100644 gems/rack/CVE-2025-61770.yml create mode 100644 gems/rack/CVE-2025-61771.yml create mode 100644 gems/rack/CVE-2025-61772.yml 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