Updated advisory posts against rubysec/ruby-advisory-db@583ff06

Author: jasnow

advisories/_posts/2025-10-10-CVE-2025-61780.md

@@ -0,0 +1,88 @@
+---
+layout: advisory
+title: 'CVE-2025-61780 (rack): Rack has a Possible Information Disclosure Vulnerability'
+comments: false
+categories:
+- rack
+advisory:
+  gem: rack
+  cve: 2025-61780
+  ghsa: r657-rxjc-j557
+  url: https://github.com/rack/rack/security/advisories/GHSA-r657-rxjc-j557
+  title: Rack has a Possible Information Disclosure Vulnerability
+  date: 2025-10-10
+  description: |
+    ## Summary
+
+    A possible information disclosure vulnerability existed in
+    `Rack::Sendfile` when running behind a proxy that supports
+    `x-sendfile` headers (such as Nginx). Specially crafted headers
+    could cause `Rack::Sendfile` to miscommunicate with the proxy and
+    trigger unintended internal requests, potentially bypassing
+    proxy-level access restrictions.
+
+    ## Details
+
+    When `Rack::Sendfile` received untrusted `x-sendfile-type` or
+    `x-accel-mapping` headers from a client, it would interpret them
+    as proxy configuration directives. This could cause the middleware
+    to send a "redirect" response to the proxy, prompting it to reissue
+    a new internal request that was
+    **not subject to the proxy's access controls**.
+
+    An attacker could exploit this by:
+    1. Setting a crafted `x-sendfile-type: x-accel-redirect` header.
+    2. Setting a crafted `x-accel-mapping` header.
+    3. Requesting a path that qualifies for proxy-based acceleration.
+
+    ## Impact
+
+    Attackers could bypass proxy-enforced restrictions and access internal
+    endpoints intended to be protected (such as administrative pages).
+    The vulnerability did not allow arbitrary file reads but could
+    expose sensitive application routes.
+
+    This issue only affected systems meeting all of the following conditions:
+
+    * The application used `Rack::Sendfile` with a proxy that supports
+      `x-accel-redirect` (e.g., Nginx).
+    * The proxy did **not** always set or remove the `x-sendfile-type`
+      and `x-accel-mapping` headers.
+    * The application exposed an endpoint that returned a body
+      responding to `.to_path`.
+
+    ## Mitigation
+
+    * Upgrade to a fixed version of Rack which requires explicit
+      configuration to enable `x-accel-redirect`:
+
+      ```ruby
+      use Rack::Sendfile, "x-accel-redirect"
+      ```
+
+    * Alternatively, configure the proxy to always set or strip
+      the headers (you should be doing this!):
+
+      ```nginx
+      proxy_set_header x-sendfile-type x-accel-redirect;
+      proxy_set_header x-accel-mapping /var/www/=/files/;
+      ```
+
+    * Or in Rails applications, disable sendfile completely:
+
+      ```ruby
+      config.action_dispatch.x_sendfile_header = nil
+      ```
+  cvss_v3: 5.8
+  patched_versions:
+  - "~> 2.2.20"
+  - "~> 3.1.18"
+  - ">= 3.2.3"
+  related:
+    url:
+    - https://github.com/rack/rack/security/advisories/GHSA-r657-rxjc-j557
+    - https://github.com/rack/rack/commit/57277b7741581fa827472c5c666f6e6a33abd784
+    - https://github.com/rack/rack/commit/7e69f65eefe9cd2868df9f9f3b0977b86f93523a
+    - https://github.com/rack/rack/commit/fba2c8bc63eb787ff4b19bc612d315fda6126d85
+    - https://github.com/advisories/GHSA-r657-rxjc-j557
+---

advisories/_posts/2025-10-10-CVE-2025-61919.md

@@ -0,0 +1,68 @@
+---
+layout: advisory
+title: 'CVE-2025-61919 (rack): Rack is vulnerable to a memory-exhaustion DoS through
+  unbounded URL-encoded body parsing'
+comments: false
+categories:
+- rack
+advisory:
+  gem: rack
+  cve: 2025-61919
+  ghsa: 6xw4-3v39-52mm
+  url: https://github.com/rack/rack/security/advisories/GHSA-6xw4-3v39-52mm
+  title: Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded
+    body parsing
+  date: 2025-10-10
+  description: |
+    ## Summary
+
+    `Rack::Request#POST` reads the entire request body into memory for
+    `Content-Type: application/x-www-form-urlencoded`, calling
+    `rack.input.read(nil)` without enforcing a length or cap. Large
+    request bodies can therefore be buffered completely into process
+    memory before parsing, leading to denial of service (DoS) through
+    memory exhaustion.
+
+    ## Details
+
+    When handling non-multipart form submissions, Rack’s request
+    parser performs:
+
+    ```ruby
+    form_vars = get_header(RACK_INPUT).read
+    ```
+
+    Since `read` is called with no argument, the entire request body is
+    loaded into a Ruby `String`. This occurs before query parameter
+    parsing or enforcement of any `params_limit`. As a result, Rack
+    applications without an upstream body-size limit can experience
+    unbounded memory allocation proportional to request size.
+
+    ## Impact
+
+    Attackers can send large `application/x-www-form-urlencoded` bodies
+    to consume process memory, causing slowdowns or termination by the
+    operating system (OOM). The effect scales linearly with request
+    size and concurrency. Even with parsing limits configured, the
+    issue occurs *before* those limits are enforced.
+
+    ## Mitigation
+
+    * Update to a patched version of Rack that enforces form parameter
+      limits using `query_parser.bytesize_limit`, preventing unbounded
+      reads of `application/x-www-form-urlencoded` bodies.
+    * Enforce strict maximum body size at the proxy or web server layer
+      (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).
+  cvss_v3: 7.5
+  patched_versions:
+  - "~> 2.2.20"
+  - "~> 3.1.18"
+  - ">= 3.2.3"
+  related:
+    url:
+    - https://github.com/rack/rack/security/advisories/GHSA-6xw4-3v39-52mm
+    - https://github.com/rack/rack/commit/4e2c903991a790ee211a3021808ff4fd6fe82881
+    - https://github.com/rack/rack/commit/cbd541e8a3d0c5830a3c9a30d3718ce2e124f9db
+    - https://github.com/rack/rack/commit/e179614c4a653283286f5f046428cbb85f21146f
+    - https://github.com/advisories/GHSA-6xw4-3v39-52mm
+---

advisories/_posts/2025-10-10-CVE-2025-61921.md

@@ -0,0 +1,49 @@
+---
+layout: advisory
+title: 'CVE-2025-61921 (sinatra): Sinatra is vulnerable to ReDoS through ETag header
+  value generation'
+comments: false
+categories:
+- sinatra
+advisory:
+  gem: sinatra
+  cve: 2025-61921
+  ghsa: mr3q-g2mv-mr4q
+  url: https://github.com/sinatra/sinatra/security/advisories/GHSA-mr3q-g2mv-mr4q
+  title: Sinatra is vulnerable to ReDoS through ETag header value generation
+  date: 2025-10-10
+  description: |
+    ### Summary
+
+    There is a denial of service vulnerability in the `If-Match` and
+    `If-None-Match` header parsing component of Sinatra, if the `etag`
+    method is used when constructing the response and you are using Ruby < 3.2.
+
+    ### Details
+
+    Carefully crafted input can cause `If-Match` and `If-None-Match`
+    header parsing in Sinatra to take an unexpected amount of time,
+    possibly resulting in a denial of service attack vector. This header
+    is typically involved in generating the `ETag` header value. Any
+    applications that use the `etag` method when generating a response
+    are impacted if they are using Ruby below version 3.2.
+
+    ### Resources
+
+    * https://github.com/sinatra/sinatra/issues/2120 (report)
+    * https://github.com/sinatra/sinatra/pull/2121 (fix)
+    * https://github.com/sinatra/sinatra/pull/1823 (older ReDoS vulnerability)
+    * https://bugs.ruby-lang.org/issues/19104 (fix in Ruby >= 3.2)
+  patched_versions:
+  - ">= 4.2.0"
+  related:
+    url:
+    - https://github.com/sinatra/sinatra/security/advisories/GHSA-mr3q-g2mv-mr4q
+    - https://github.com/sinatra/sinatra/issues/2120
+    - https://github.com/sinatra/sinatra/pull/1823
+    - https://github.com/sinatra/sinatra/pull/2121
+    - https://github.com/sinatra/sinatra/commit/3fe8c38dc405586f7ad8f2ac748aa53e9c3615bd
+    - https://github.com/sinatra/sinatra/commit/8ff496bd4877520599e1479d6efead39304edceb
+    - https://bugs.ruby-lang.org/issues/19104
+    - https://github.com/advisories/GHSA-mr3q-g2mv-mr4q
+---