CVE-2025-32441: Rack Race Condition Vulnerability

CVE-2025-32441 Overview

CVE-2025-32441 is a race condition vulnerability affecting Rack, a modular Ruby web server interface. When using the Rack::Session::Pool middleware, simultaneous rack requests can restore a deleted rack session, allowing an unauthenticated user to occupy that session. This vulnerability enables attackers who have acquired a session cookie to retain illicit access even after a legitimate user has attempted to logout.

Critical Impact

Attackers can exploit this race condition to maintain unauthorized session access after user logout, potentially leading to account takeover and unauthorized access to sensitive data.

Affected Products

• Rack versions prior to 2.2.14
• Ruby web applications using Rack::Session::Pool middleware

Discovery Timeline

• 2025-05-07 - CVE-2025-32441 published to NVD
• 2025-06-17 - Last updated in NVD database

Technical Details for CVE-2025-32441

Vulnerability Analysis

This vulnerability stems from the inherent race condition in how Rack session middleware processes concurrent requests. The session middleware prepares the session at the beginning of a request and saves it back to the store with possible changes applied by the host rack application. This design makes the session subject to race conditions when handling concurrent rack requests.

The attack scenario requires an attacker to first acquire a valid session cookie. Once obtained, the attacker can trigger a long-running request within that same session adjacent to the user logging out. Due to the race condition, the session may be restored, allowing the attacker to retain access even after the legitimate user has logged out.

Root Cause

The root cause is a Time-of-Check Time-of-Use (TOCTOU) race condition (CWE-362) in the Rack::Session::Pool middleware. When a session is deleted during logout, concurrent requests that began before the deletion can write the session data back to the pool, effectively restoring the deleted session. The vulnerable code in lib/rack/session/abstract/id.rb does not verify that the session still exists before writing session data back to the store.

Attack Vector

The attack is network-based and requires the following conditions:

1. The attacker must acquire a valid session cookie (through session theft, XSS, or other means)
2. The attacker initiates a long-running request using the stolen session
3. The legitimate user logs out, which deletes the session
4. The attacker's long-running request completes and writes session data back to the pool
5. The session is effectively restored, granting the attacker continued access

 
      def write_session(req, session_id, new_session, options)
        with_lock(req) do
+          return false unless get_session_with_fallback(session_id)
          @pool.store session_id.private_id, new_session
          session_id
        end

Source: GitHub Rack Commit Update

The patch adds a verification check (get_session_with_fallback) to ensure the session still exists before writing data back to the pool, preventing restored sessions from being written after deletion.

Detection Methods for CVE-2025-32441

Indicators of Compromise

• Unusual session activity patterns where sessions appear to remain active after logout events
• Multiple concurrent requests using the same session ID with significantly different request durations
• Session IDs being used after explicit session destruction events in application logs

Detection Strategies

• Monitor for concurrent requests from the same session ID where one request has abnormally long execution time
• Implement logging for session lifecycle events (creation, destruction, modification) and correlate with authentication events
• Audit application logs for session reuse after logout operations

Monitoring Recommendations

• Enable detailed session logging in your Rack application to track session state changes
• Configure application monitoring to alert on session anomalies such as sessions being written after destruction
• Review server access logs for patterns indicating long-running requests coinciding with logout events

How to Mitigate CVE-2025-32441

Immediate Actions Required

• Upgrade Rack to version 2.2.14 or later immediately
• Review application logs for any signs of session persistence after logout events
• Consider implementing additional session validation at the application level as defense-in-depth

Patch Information

Rack version 2.2.14 contains the official patch for this vulnerability. The fix adds a verification check in the write_session method to ensure the session still exists before writing data back to the session pool. Organizations should update their Rack gem dependency immediately.

For detailed patch information, refer to the GitHub Security Advisory GHSA-vpfw-47h7-xj4g and the patch commit.

Workarounds

• Implement atomic session invalidation by using a logged_out flag instead of deleting sessions, and check this flag on every request to prevent reuse
• Create a custom session store that tracks session invalidation timestamps and refuses to accept session data if the session was invalidated after the request began
• Consider switching to a different session store implementation that is not affected by this specific race condition

# Update Rack gem to patched version
bundle update rack

# Verify the installed version
bundle show rack
# Expected output: rack-2.2.14 or higher