CVE-2025-32441

What it actually does

A race condition vulnerability exists in the `Rack::Session::Pool` middleware. When handling simultaneous requests, it is possible for a session that has been marked for deletion to be restored and reused by a new, unauthenticated request. This can lead to session fixation or session hijacking, where an attacker can occupy a previously valid session identifier, potentially inheriting session data or state if the application logic is not robust.

Why it matters to the business

This vulnerability could allow an attacker to take over another user's session, potentially leading to unauthorized access to sensitive information or the ability to perform actions on behalf of the victim. This can result in data breaches, loss of user privacy, and erosion of trust in the application. The exploitability is complex, requiring precise timing, which lowers the immediate risk, but a successful attack could have a significant impact on individual user accounts.

How an attack unfolds

An attacker would first identify an application using the vulnerable `Rack::Session::Pool` middleware. The attacker would then need to orchestrate the sending of at least two simultaneous requests to the target application. One request would trigger the deletion of a session (e.g., by hitting a logout endpoint), while the other, timed to arrive at the exact same moment, would initiate a new session. Due to the race condition, the new session request could successfully restore and occupy the session ID that was in the process of being deleted, effectively hijacking it.

How to fix it

Update the `rack` gem to a version that includes the fix from commit `d0dcf75706d72d7e874ee31934a97881c1a439ce`. Developers should review their project's dependencies and update to the latest secure version of Rack. As a temporary mitigation if patching is not immediately possible, consider switching from `Rack::Session::Pool` to an alternative session store (e.g., `Rack::Session::Cookie` or a database-backed store) that provides stronger atomicity guarantees for session operations.

How to confirm the fix worked

To confirm remediation, check the installed version of the `rack` gem in your application's environment to ensure it incorporates the security patch. You can use your package manager (e.g., `bundle show rack`) to verify the version. Automated dependency scanning tools can also be used to flag vulnerable versions. While difficult to test reliably, penetration testing could attempt to reproduce the race condition against a test environment to confirm the fix.

Typical attack path

1. Identify a target application using the vulnerable `Rack::Session::Pool` middleware.
2. Craft two concurrent requests: one to trigger a session deletion and another to initiate a new session.
3. Send the requests simultaneously to the server to trigger the race condition.
4. If successful, the attacker's request re-uses the just-deleted session ID.
5. The attacker now controls a session that may contain stale data or have unintended associations from its previous owner.

How to detect it

Detecting exploitation of this race condition is challenging as it relies on observing behavior rather than static signatures. Monitor web server and application logs for an unusually high rate of concurrent requests from a single source IP, particularly targeting session creation and deletion endpoints. Analyze session lifecycle events for anomalies, such as a session ID being destroyed and then immediately reused by a request with a different user agent or from a different IP address.

What your security team should do

• Immediately identify all Ruby applications using the `Rack::Session::Pool` middleware and prioritize them for patching.
• Update the `rack` gem to a patched version in all affected applications.
• If patching is delayed, advise development teams to switch to a more robust session management backend as a compensating control.