GHSA SYNC: 3 brand new advisories

gems/rack-session/CVE-2025-46336.yml

@@ -0,0 +1,58 @@
+---
+gem: rack-session
+cve: 2025-46336
+ghsa: 9j94-67jr-4cqj
+url: https://github.com/rack/rack-session/security/advisories/GHSA-9j94-67jr-4cqj
+title: Rack session gets restored after deletion
+date: 2025-05-08
+description: |
+  ## Summary
+
+  When using the `Rack::Session::Pool` middleware, simultaneous rack
+  requests can restore a deleted rack session, which allows the
+  unauthenticated user to occupy that session.
+
+  ## Details
+
+  [Rack session middleware](https://github.com/rack/rack-session/blob/v2.1.0/lib/rack/session/abstract/id.rb#L271-L278)
+  prepares the session at the beginning of request, then saves is back
+  to the store with possible changes applied by host rack application.
+  This way the session becomes to be a subject of race conditions in
+  general sense over concurrent rack requests.
+
+  ## Impact
+
+  When using the `Rack::Session::Pool` middleware, and provided the
+  attacker can acquire a session cookie (already a major issue), the
+  session may be restored if the attacker can trigger a long running
+  request (within that same session) adjacent to the user logging out,
+  in order to retain illicit access even after a user has attempted to logout.
+
+  ## Mitigation
+
+  - Update to the latest version of `rack-session`, or
+  - Ensure your application invalidates sessions atomically by marking
+    them as logged out e.g., using a `logged_out` flag, instead of
+    deleting them, and check this flag on every request to prevent reuse, or
+  - Implement a custom session store that tracks session invalidation
+    timestamps and refuses to accept session data if the session was
+    invalidated after the request began.
+
+  ## Related
+
+  This code was previously part of `rack` in Rack < 3, see
+  <https://github.com/rack/rack/security/advisories/GHSA-vpfw-47h7-xj4g>
+  for the equivalent advisory in `rack` (affecting Rack < 3 only).
+cvss_v3: 4.2
+unaffected_versions:
+  - "< 2.0.0"
+patched_versions:
+  - ">= 2.1.1"
+related:
+  ghsa:
+    - https://github.com/rack/rack/security/advisories/GHSA-vpfw-47h7-xj4g
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2025-46336
+    - https://github.com/rack/rack-session/commit/c28c4a8c1861d814e09f2ae48264ac4c40be2d3b
+    - https://github.com/rack/rack-session/security/advisories/GHSA-9j94-67jr-4cqj
+    - https://github.com/advisories/GHSA-9j94-67jr-4cqj

gems/rack/CVE-2025-32441.yml

@@ -0,0 +1,57 @@
+---
+gem: rack
+cve: 2025-32441
+ghsa: vpfw-47h7-xj4g
+url: https://github.com/rack/rack-session/security/advisories/GHSA-9j94-67jr-4cqj
+title: Rack session gets restored after deletion
+date: 2025-05-08
+description: |
+  ### Summary
+
+  When using the `Rack::Session::Pool` middleware, simultaneous rack
+  requests can restore a deleted rack session, which allows the
+  unauthenticated user to occupy that session.
+
+  ### Details
+
+  [Rack session middleware](https://github.com/rack/rack/blob/v2.2.13/lib/rack/session/abstract/id.rb#L263-L270)
+  prepares the session at the beginning of request, then saves is back
+  to the store with possible changes applied by host rack application.
+  This way the session becomes to be a subject of race conditions in
+  general sense over concurrent rack requests.
+
+  ### Impact
+
+  When using the `Rack::Session::Pool` middleware, and provided the
+  attacker can acquire a session cookie (already a major issue), the
+  session may be restored if the attacker can trigger a long running
+  request (within that same session) adjacent to the user logging out,
+  in order to retain illicit access even after a user has attempted to logout.
+
+  ## Mitigation
+
+  - Update to the latest version of `rack`, or
+  - Ensure your application invalidates sessions atomically by marking
+    them as logged out e.g., using a `logged_out` flag, instead of
+    deleting them, and check this flag on every request to prevent reuse, or
+  - Implement a custom session store that tracks session invalidation
+    timestamps and refuses to accept session data if the session was
+    invalidated after the request began.
+
+  ### Related
+
+  As this code was moved to `rack-session` in Rack 3+, see
+  <https://github.com/rack/rack-session/security/advisories/GHSA-9j94-67jr-4cqj>
+  for the equivalent advisory in `rack-session` (affecting Rack 3+ only).
+cvss_v3: 4.2
+patched_versions:
+  - ">= 2.2.14"
+related:
+  ghsa:
+    - https://github.com/rack/rack-session/security/advisories/GHSA-9j94-67jr-4cqj
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2025-32441
+    - https://github.com/rack/rack/security/advisories/GHSA-vpfw-47h7-xj4g
+    - https://github.com/rack/rack/commit/c48e52f7c57e99e1e1bf54c8760d4f082cd1c89d
+    - https://github.com/rack/rack/blob/v2.2.13/lib/rack/session/abstract/id.rb#L263-L270
+    - https://github.com/advisories/GHSA-vpfw-47h7-xj4g

gems/rack/CVE-2025-46727.yml

@@ -0,0 +1,53 @@
+---
+gem: rack
+cve: 2025-46727
+ghsa: gjh7-p2fx-99vx
+url: https://github.com/rack/rack/security/advisories/GHSA-gjh7-p2fx-99vx
+title: Rack has an Unbounded-Parameter DoS in Rack::QueryParser
+date: 2025-05-08
+description: |
+  ## Summary
+
+  `Rack::QueryParser` parses query strings and
+  `application/x-www-form-urlencoded` bodies into Ruby data structures
+  without imposing any limit on the number of parameters, allowing
+  attackers to send requests with extremely large numbers of parameters.
+
+  ## Details
+
+  The vulnerability arises because `Rack::QueryParser` iterates over
+  each `&`-separated key-value pair and adds it to a Hash without
+  enforcing an upper bound on the total number of parameters. This
+  allows an attacker to send a single request containing hundreds of
+  thousands (or more) of parameters, which consumes excessive memory
+  and CPU during parsing.
+
+  ## Impact
+
+  An attacker can trigger denial of service by sending specifically
+  crafted HTTP requests, which can cause memory exhaustion or pin CPU
+  resources, stalling or crashing the Rack server. This results in
+  full service disruption until the affected worker is restarted.
+
+  ## Mitigation
+
+  - Update to a version of Rack that limits the number of parameters parsed, or
+  - Use middleware to enforce a maximum query string size or parameter count, or
+  - Employ a reverse proxy (such as Nginx) to limit request sizes and
+    reject oversized query strings or bodies.
+
+  Limiting request body sizes and query string lengths at the web
+  server or CDN level is an effective mitigation.
+cvss_v3: 7.5
+patched_versions:
+  - "~> 2.2.14"
+  - "~> 3.0.16"
+  - ">= 3.1.14"
+related:
+  url:
+    - https://nvd.nist.gov/vuln/detail/CVE-2025-46727
+    - https://github.com/rack/rack/security/advisories/GHSA-gjh7-p2fx-99vx
+    - https://github.com/rack/rack/commit/2bb5263b464b65ba4b648996a579dbd180d2b712
+    - https://github.com/rack/rack/commit/3f5a4249118d09d199fe480466c8c6717e43b6e3
+    - https://github.com/rack/rack/commit/cd6b70a1f2a1016b73dc906f924869f4902c2d74
+    - https://github.com/advisories/GHSA-gjh7-p2fx-99vx