CVE-2025-46336

What it actually does

This flaw affects Rack applications using Rack::Session::Pool in Rack::Session versions 2.0.0 through versions before 2.1.1. If an attacker already possesses a valid session cookie, they may be able to preserve or restore that session by keeping a long-running request active while the legitimate user logs out. The result is incomplete session invalidation: the logout action may not reliably terminate access for all in-flight requests associated with the same session. The issue does not provide initial authentication bypass by itself; exploitation depends on prior session cookie theft or acquisition and precise request timing.

Why it matters to the business

An affected application may fail to fully terminate a compromised user session after logout, allowing an attacker who already stole a session cookie to continue accessing the application. This can lead to unauthorized viewing or modification of user data, failed user expectations around logout, and increased incident-response complexity. The practical risk is moderated by the need for a preexisting stolen session cookie, use of Rack::Session::Pool, and a timing condition; EPSS is low and the issue is not listed in CISA KEV, but internet-facing applications that handle sensitive accounts should still remediate because session persistence after logout undermines account security controls.

How an attack unfolds

An attacker first obtains a valid session cookie through a separate weakness such as malware, browser compromise, insecure transport, log leakage, cross-site scripting, or another session exposure path. The attacker then sends authenticated requests using that cookie and deliberately initiates a request that remains active for an extended period. If the legitimate user logs out while the attacker's long-running request is still in progress, vulnerable Rack::Session::Pool behavior can allow the session state to be restored or retained after logout. The attacker can then continue using the same session cookie to access application functionality that the user expected to have been terminated.

How to fix it

Upgrade Rack::Session/Rack to version 2.1.1 or later, or apply the upstream fix identified by commit 799a520a015de5938bc01faa8e90b76589c6e7d3 where source-based patching is used. The vulnerable range is 2.0.0 through versions before 2.1.1 when Rack::Session::Pool middleware is in use. For SUSE live patching packages listed as affected, update kernel-livepatch-SLE15-SP3_Update_46 to 2-150300.7.6.1 or later and kernel-livepatch-SLE15-SP2_Update_50 to 2-150200.5.6.1 or later, where applicable. If immediate upgrade is not possible, reduce exposure by replacing Rack::Session::Pool with a session backend that has strong server-side invalidation semantics, enforcing short session lifetimes, rotating session identifiers after authentication and privilege changes, invalidating all sessions on logout where supported, and investigating and fixing any path that could leak session cookies.

How to confirm the fix worked

Confirm both package version and runtime configuration. Review dependency manifests such as Gemfile.lock, gemspec files, container build artifacts, SBOMs, and deployed package inventories for Rack::Session or Rack versions from 2.0.0 up to but not including 2.1.1. Verify whether the application actually configures Rack::Session::Pool; applications not using this middleware are not exposed to the described behavior. After upgrading, confirm the deployed application loads Rack::Session/Rack 2.1.1 or later at runtime, not just in source control. Functional validation should include a logout test where an authenticated long-running request is active while logout occurs, followed by an attempt to reuse the same session cookie; the reused cookie should no longer grant authenticated access.

Typical attack path

1. Acquire a valid session cookie for a target user through a separate compromise or leakage path.
2. Confirm that the cookie grants authenticated access to the Rack-based application.
3. Start one or more long-running authenticated requests using the stolen cookie.
4. Time the long-running request so it overlaps with or occurs adjacent to the legitimate user's logout action.
5. Rely on the vulnerable session handling behavior to preserve or restore the session after logout.
6. Continue sending authenticated requests with the same session cookie after the user believes the session has ended.

How to detect it

There is no universal network signature for this issue because exploitation looks like normal authenticated traffic using a valid session cookie. Focus on application, web access, authentication, and audit logs. Look for authenticated requests that continue after a recorded logout event using the same session identifier, cookie-derived session, account, or client fingerprint. Pay particular attention to long-running requests that begin shortly before or during logout and complete after logout, followed by additional successful authenticated requests without a new login. Investigate cases where the same session is used from multiple IP addresses, autonomous systems, geolocations, or user agents, especially around a logout event. Review application logs for session restore, session write, session delete, and session invalidation events occurring in an unexpected order. If session IDs are not logged, correlate by account, request timestamps, user agent, source address, logout events, and post-logout access. Also investigate the likely prerequisite compromise: cookie leakage in proxy logs, application logs, browser malware telemetry, XSS findings, insecure HTTP access, or exposed debugging output.

What your security team should do

• Prioritize identifying internet-facing or sensitive Rack applications that use Rack::Session::Pool and Rack::Session versions 2.0.0 through before 2.1.1.
• Upgrade affected applications to Rack::Session/Rack 2.1.1 or later, or apply the upstream fixed commit 799a520a015de5938bc01faa8e90b76589c6e7d3.
• Treat this as a session-hardening issue: review protections against session cookie theft, including TLS enforcement, Secure and HttpOnly cookie flags, SameSite policy, XSS prevention, and avoidance of cookie logging.
• Add or improve audit logging for login, logout, session invalidation, session identifier rotation, source IP, user agent, and request duration so future exploitation attempts can be investigated.
• Search for evidence of session reuse after logout, especially where the same session appears from different IP addresses or user agents.
• If suspicious activity is found, invalidate active sessions, force reauthentication, rotate relevant secrets if cookie signing or encryption keys may be exposed, and investigate the original session theft vector.
• Do not rely solely on logout as a compensating control until affected deployments are patched and validated.