CVE-2025-66803
BaseFortify
Publication date: 2026-01-20
Last updated on: 2026-01-30
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| hotwired | turbo | to 8.0.21 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-362 | The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection of this vulnerability involves monitoring for delayed or out-of-order HTTP responses from <turbo-frame> requests that carry Set-Cookie headers resetting session cookies after logout or session changes. Since the issue arises from race conditions with slow-loading turbo-frame requests, you can detect it by capturing and analyzing HTTP traffic for such delayed responses that overwrite session cookies. Commands to assist in detection include using network traffic capture tools like tcpdump or Wireshark to filter HTTP responses with Set-Cookie headers related to turbo-frame requests. For example, using tcpdump: `tcpdump -i <interface> -A 'tcp port 80 or tcp port 443' | grep -i Set-Cookie` to monitor cookie-setting responses. Additionally, browser developer tools' network tab can be used to observe the timing and order of turbo-frame requests and their Set-Cookie headers. There is no specific built-in command provided in the resources, but monitoring for delayed or out-of-order Set-Cookie headers in turbo-frame responses is key to detecting exploitation or occurrence of this race condition. [1, 3]
Can you explain this vulnerability to me?
This vulnerability is a race condition in the Hotwired Turbo framework's turbo-frame element handler. When a user performs a logout or other session-changing operation, a delayed response from a previously initiated turbo-frame request can overwrite the updated session cookie with stale values. This happens because browsers automatically process Set-Cookie headers from HTTP responses, so if a slow turbo-frame response arrives after the session change, it can revert the session state unintentionally. Attackers can exploit this by selectively delaying network responses or it can occur naturally on shared computers. The root cause is that in-flight turbo-frame fetch requests are not canceled when the frame is disconnected or disabled, allowing stale responses to reset cookies. [1, 3]
How can this vulnerability impact me? :
This vulnerability can cause session state reversion, meaning that after a user logs out, their session cookies might be reset to a previous authenticated state due to delayed turbo-frame responses. This can lead to unintended restoration of prior authentication states, effectively allowing an attacker or a race condition to bypass logout and maintain access. Applications using client-side cookie-based session storage are particularly affected. This can compromise user session integrity and security, potentially allowing unauthorized access or session hijacking. Applications using server-side session storage are less affected. [1, 3]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading the Hotwired Turbo framework to version 8.0.21 or later, which cancels in-flight Turbo Frame requests when the frame is disconnected from the DOM, disabled, or its src attribute is cleared, preventing stale responses from resetting session cookies. Additionally, ensure logout flows remove or disable Turbo Frame elements before session invalidation. As a workaround, consider using server-side session storage instead of cookie-based session storage to avoid session state reversion caused by delayed frame responses. [1, 3]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability can cause session state reversion or unintended restoration of prior authentication states due to delayed HTTP responses resetting session cookies. Such behavior may lead to unauthorized access or failure to properly terminate user sessions, potentially violating security requirements in standards like GDPR and HIPAA that mandate strict session management and protection of personal data. Applications relying on client-side cookie-based session storage are particularly affected, increasing the risk of non-compliance with these regulations. Using server-side session storage or applying the fixes in Turbo version 8.0.21 and later mitigates these risks. [3]