Vulnerability Instance

Rack session gets restored after deletion
### 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).