Evidence used
- No CISA KEV confirmation is currently recorded.
- EPSS is 0.62% for the current model date.
BlackTreeCVE Intelligencefastify · fastify-secure-session
Official source article: GitHub GHSA-9WWP-Q7WQ-JX35 ↗. Check the applicable product and release in the original source.
High technical severity; prioritise exposed affected systems while verifying vendor guidance.
These OSV and GitHub advisory ranges apply only to the named package and ecosystem. A listed fixed version is not a universal product patch or proof that an update is installed.
| Ecosystem and package | Affected range | First fixed version | Evidence |
|---|---|---|---|
| npm@fastify/secure-session | SEMVER: introduced 0; fixed 7.3.0 | 7.3.0 | OSV record ↗aggregator derived · 10 Sep 2026 |
High technical severity; prioritise exposed affected systems while verifying vendor guidance.
Fix not verified@festify/secure-session creates a secure stateless cookie session for Fastify. At the end of the request handling, it will encrypt all data in the session with a secret key and attach the ciphertext as a cookie value with the defined cookie name. After that, the session on the server side is destroyed. When an encrypted cookie with matching session name is provided with subsequent requests, it will decrypt the ciphertext to get the data. The plugin then creates a new session with the data in the ciphertext. Thus theoretically the web instance is still accessing the data from a server-side session, but technically that session is generated solely from a user provided cookie (which is assumed to be non-craftable because it is encrypted with a secret key not known to the user). The issue exists in the session removal process. In the delete function of the code, when the session is deleted, it is marked for deletion. However, if an attacker could gain access to the cookie, they could keep using it forever. Version 7.3.0 contains a patch for the issue. As a workaround, one may include a "last update" field in the session, and treat "old sessions" as expired.
@festify/secure-session creates a secure stateless cookie session for Fastify. At the end of the request handling, it will encrypt all data in the session with a secret key and attach the ciphertext as a cookie value with the defined cookie name. After that, the session on the server side is destroyed. When an encrypted cookie with matching session name is provided with subsequent requests, it will decrypt the ciphertext to get the data. The plugin then creates a new session with the data in the ciphertext. Thus theoretically the web instance is still accessing the data from a server-side session, but technically that session is generated solely from a user provided cookie (which is assumed to be non-craftable because it is encrypted with a secret key not known to the user). The issue exists in the session removal process. In the delete function of the code, when the session is deleted, it is marked for deletion. However, if an attacker could gain access to the cookie, they could keep using it forever. Version 7.3.0 contains a patch for the issue. As a workaround, one may include a "last update" field in the session, and treat "old sessions" as expired.
According to WASC, Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization.
An attacker operating through a network path may attempt exploitation without authentication after a user interaction. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
@festify/secure-session creates a secure stateless cookie session for Fastify. At the end of the request handling, it will encrypt all data in the session with a secret key and attach the ciphertext as a cookie value with the defined cookie name. After that, the session on the server side is destroyed. When an encrypted cookie with matching session name is provided with subsequent requests, it will decrypt the ciphertext to get the data. The plugin then creates a new session with the data in the ciphertext. Thus theoretically the web instance is still accessing the data from a server-side session, but technically that session is generated solely from a user provided cookie (which is assumed to be non-craftable because it is encrypted with a secret key not known to the user). The issue exists in the session removal process. In the delete function of the code, when the session is deleted, it is marked for deletion. However, if an attacker could gain access to the cookie, they could keep using it forever. Version 7.3.0 contains a patch for the issue. As a workaround, one may include a "last update" field in the session, and treat "old sessions" as expired.
According to WASC, Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization.
An attacker operating through a network path may attempt exploitation without authentication after a user interaction. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CWE-613: Insufficient Session Expiration. According to WASC, Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization.
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:NCommon Vulnerability Scoring System 3.1: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 10 Apr 2024 · Last source change 2 Aug 2024, 01:59 UTC · CWE-613 · Insufficient Session Expiration
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.