@fastify/secure-session CVE-2026-117549

Exploitation requires a specific, non-default operational pattern, all of which must hold: (1) the plugin is configured with cookie.signed: true; (2) the @fastify/cookie signing secret is supplied independently of the session encryption key; and (3) the operator rotates ONLY the signing secret to retire existing sessions while leaving the session encryption key active. In addition, the attacker must already possess an unexpired encrypted session cookie from before the rotation. Key limiting factors: it does not work against default single-secret setups, the attacker needs neither secret but cannot create a session they never had, cannot forge or modify session contents, cannot extend session expiry, and is fully defeated by rotating the session encryption key (the first entry in the key array) - which is also the documented workaround. These constraints make real-world exploitability narrow despite the network attack vector.

This is a genuinely low-to-moderate priority issue rather than a high-urgency one, and the signals agree. The CVSS 3.1 base score is 4.2 (Medium) with vector AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N: network-reachable but high complexity, requiring low privileges and no user interaction, with only Low confidentiality and integrity impact and no availability impact. The vuln.today decision label is 'this_month', consistent with a moderate, non-emergency fix cadence. No EPSS probability was provided in the input, so exploitation likelihood cannot be quantified. The vulnerability is NOT on the CISA KEV list and there is no public exploit identified at time of analysis - the only references are the GHSA/OpenJS advisory itself, not working exploit code. The AC:H and the real-world impact are gated by a narrow operational pattern (see exploitation_conditions): it only matters when an operator rotates the cookie signing secret alone, independently of the still-active session encryption key. Note a nuance in the PR:L rating: the attacker does not need either secret, but must already hold a previously-valid (now supposedly retired) encrypted session cookie, which is why PR:L rather than PR:N is appropriate. The attacker cannot forge session data, extend expiry, or survive rotation of the encryption key, which caps the practical blast radius. Net: a real correctness/access-control defect worth patching, but not a widespread or weaponizable threat on current evidence.

An operator rotates only the @fastify/cookie signing secret to invalidate existing sessions while keeping the session encryption key unchanged. A user who still holds an old, unexpired encrypted session cookie strips the now-invalid signature from it and resubmits it; because the plugin decrypts the value even though unsignCookie reported the signature invalid, the supposedly-retired session continues to work. No public exploit code is identified at time of analysis, and the attacker needs neither the signing secret nor the encryption key.