diff --git a/gems/rack-session/CVE-2025-46336.yml b/gems/rack-session/CVE-2025-46336.yml new file mode 100644 index 0000000000..207161a400 --- /dev/null +++ b/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 + + 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 diff --git a/gems/rack/CVE-2025-32441.yml b/gems/rack/CVE-2025-32441.yml new file mode 100644 index 0000000000..c7c7615f20 --- /dev/null +++ b/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 + + 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 diff --git a/gems/rack/CVE-2025-46727.yml b/gems/rack/CVE-2025-46727.yml new file mode 100644 index 0000000000..bc30a52735 --- /dev/null +++ b/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