CVE-2026-117499 in session
Summary
by MITRE • 10/27/2026
@fastify/session is a session plugin for Fastify. In all releases before 11.1.6, with the default rolling session behavior, a request that restored a session before a logout could save its own copy after another request had completed the session destroy call, recreating the destroyed session identifier with its authenticated data. An attacker who already holds a victim's valid signed session cookie and keeps a request in flight across the logout can replay that cookie to restore the session after it was meant to be revoked, without any cookie theft or signature forgery. The issue is fixed in @fastify/session 11.1.6, which adds a per session generation marker and a conditional store write so a session restored before a logout or regeneration cannot recreate or overwrite the current entry, and users should upgrade to 11.1.6 or later. There is no workaround, and custom session stores must implement the new conditional write.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in @fastify/session versions prior to 11.1.6 represents a critical race condition within the session management logic that undermines the integrity of authentication states. This flaw specifically targets applications utilizing the default rolling session behavior, where session expiration timers are reset upon each request. The core technical failure lies in the lack of atomicity between reading an existing session and writing updated data back to the store during concurrent operations. When a user initiates a logout sequence, the server is expected to destroy the current session identifier and invalidate its associated authenticated data. However, if another active request from the same client restores that identical session cookie before the destruction process completes, it retrieves the stale session state containing valid authentication credentials. Subsequently, when this lingering request finishes processing, it writes its copy of the session back to the store, effectively overwriting or recreating the destroyed session identifier with its original authenticated data. This sequence allows an attacker who possesses a victim's signed session cookie to bypass logout mechanisms simply by maintaining a long-running request that spans across the logout event, thereby replaying the valid credentials after they were intended to be revoked.
From a security architecture perspective, this vulnerability is classified under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization of Session Management flaws. It aligns closely with MITRE ATT&CK technique T1078, specifically Valid Accounts and subsequent session manipulation tactics where an adversary maintains access despite administrative revocation attempts. The impact is severe because it allows for unauthorized persistence in a system without requiring any cookie theft or cryptographic signature forgery. Since the session cookies are signed using secure algorithms like HMAC, their validity cannot be easily forged by external parties. Instead, the exploit relies entirely on timing and concurrency issues inherent to non-atomic store operations. An attacker can leverage this race condition to maintain active sessions indefinitely, potentially leading to unauthorized access to sensitive user data, privilege escalation if session roles are not properly invalidated, or further exploitation within the application context that assumes a logged-out state is secure.
The remediation for this issue was implemented in version 11.1.6 of @fastify/session through architectural changes designed to enforce strict consistency during concurrent access. The fix introduces a per-session generation marker, which acts as an optimistic locking mechanism. When a session is restored from the store, its current generation count is recorded. Before any write operation occurs, the system checks if the stored generation matches the one read at the start of the request. If a logout or regeneration has occurred in between, the generation counter would have incremented, causing the conditional check to fail and preventing the stale data from overwriting the newer state. Additionally, the store implementation now utilizes conditional writes that reject updates based on this version mismatch. This ensures that only the most recent valid session state is preserved, effectively neutralizing the race condition.
For organizations relying on custom or third-party session stores with @fastify/session, upgrading to 11.1.6 alone may not be sufficient if the underlying store does not support atomic conditional writes based on versioning. There are no alternative workarounds such as configuration changes that can mitigate this flaw; the only viable solution is a software upgrade combined with ensuring compatibility of the session storage backend. Developers must verify that their custom stores implement the new conditional write logic required by the updated library to prevent stale data from being persisted after concurrent modifications have occurred. Failure to update either the framework or the store implementation leaves systems vulnerable to this specific class of concurrency-based authentication bypass attacks, which remain a persistent challenge in distributed session management architectures.