https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-06T12:39:14.098661+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2025-07427 bdu:2025-07427 2026-10-06T12:39:14.125651+00:00 bdu:2025-07427 https://cve.radiocsirt.org/vuln/euvd-2026-238594 EUVD-2026-238594 2026-10-06T12:39:14.125695+00:00 EUVD-2026-238594 https://cve.radiocsirt.org/vuln/fkie_cve-2025-46336 fkie_cve-2025-46336 2026-10-06T12:39:14.125711+00:00

Rack::Session is a session management implementation for Rack. In versions starting from 2.0.0 to before 2.1.1, 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. This issue has been patched in version 2.1.1.

 https://cve.radiocsirt.org/vuln/ghsa-9j94-67jr-4cqj GHSA-9j94-67jr-4cqj — Rack session gets restored after deletion 2026-10-06T12:39:14.125767+00:00

Affected: RubyGems: rack-session

## 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-…

 https://cve.radiocsirt.org/vuln/opensuse-su-2025:15623-1 openSUSE-SU-2025:15623-1 — ruby3.4-rubygem-rack-session-2.1.1-1.1 on GA media 2026-10-06T12:39:14.125839+00:00

ruby3.4-rubygem-rack-session-2.1.1-1.1 on GA media

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-46336 UBUNTU-CVE-2025-46336 2026-10-06T12:39:14.125873+00:00

Affected: Ubuntu:Pro:14.04:LTS: ruby-rack, Ubuntu:Pro:16.04:LTS: ruby-rack, Ubuntu:Pro:18.04:LTS: ruby-rack, Ubuntu:Pro:20.04:LTS: ruby-rack, Ubuntu:22.04:LTS: ruby-rack, Ubuntu:24.04:LTS: ruby-rack, Ubuntu:25.04: ruby-rack

Rack::Session is a session management implementation for Rack. In versions starting from 2.0.0 to before 2.1.1, 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. This issue has been patched in version 2.1.1.