@fastify/session EUVD-2026-110811

Exploitation requires ALL of the following concrete conditions, per the advisory: the default rolling session behavior (rolling: true) must be in effect; the attacker must ALREADY possess the victim's valid signed session cookie (the flaw involves no cookie theft or signature forgery); and the attacker must keep a request that restored the session in flight so that it completes its store write AFTER another request's Session#destroy() (logout) or session regeneration - i.e., winning a narrow timing race. Limiting factors: the attack only extends/recreates a session the attacker could already use, it cannot create initial access; it depends on a concurrent logout or regeneration event occurring; and it requires hitting the race window (AC:H). Custom session stores that do not implement the new conditional write remain exposed even after upgrade.

This is a genuinely low-priority issue by every available signal, and the signals are internally consistent rather than conflicting. The vendor-supplied CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N yields only 3.7 (Low): although the attack vector is network (AV:N), exploitation is gated by high attack complexity (AC:H, reflecting the narrow race window described), already-held privileges (PR:L - the attacker must possess the victim's valid signed session cookie), and a dependent logout/user action (UI:R), with only low confidentiality and integrity impact and no availability impact. The vuln.today decision label is 'monitor', the weakest urgency tier, which agrees with the low CVSS. There is no CISA KEV listing and no EPSS score was supplied, so widespread or automated exploitation cannot be asserted; absence of EPSS is a data gap, not evidence either way. The only references are the GHSA advisory and the OpenJS CNA page - neither is a working exploit - so there is no public exploit identified at time of analysis. The practical ceiling on risk is the precondition that the attacker must already hold the victim's valid signed cookie (no cookie theft or signature forgery is part of this flaw), meaning this escalates an existing session-compromise into post-logout persistence rather than granting initial access. Net: a real correctness/security defect worth patching on a normal cycle, but not an emergency.

An attacker who has already obtained a victim's valid signed @fastify/session cookie (through some separate compromise) issues a request that reads/restores the session and deliberately keeps it in flight while the victim - or the application - performs a logout that destroys the session. Because the default rolling behavior re-saves the in-flight request's copy after the destroy completes, the destroyed session identifier is recreated with its authenticated data, and the attacker can then replay the original cookie to access the account despite the logout. No public exploit code was identified; the race requires precise timing across the logout (consistent with AC:H).