CWE-613
Insufficient Session Expiration
BaseIncomplete
Description
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
Hierarchy (View 1000)
Parents
Children
none
CVEs mapped to this weakness (96)
page 3 of 5| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2026-43911 | Med | 0.44 | 6.8 | 0.00 | May 11, 2026 | Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.35.5, refresh tokens are not invalidated when the user's security_stamp is rotated by some security-sensitive operations (password change, KDF change, key rotation, email change, org admin password reset, emergency access takeover). This allows an attacker holding a previously obtained refresh token to maintain session access even after the user has taken action to secure their account. This vulnerability is fixed in 1.35.5. | |
| CVE-2026-40934 | Med | 0.44 | 6.8 | 0.00 | May 5, 2026 | Jupyter Server is the backend for Jupyter web applications. In versions 2.17.0 and earlier, the secret used to sign authentication cookies is persisted to a static file at ~/.local/share/jupyter/runtime/jupyter_cookie_secret and is never rotated when a user changes their password. After a password reset and server restart, any previously issued authentication cookie remains cryptographically valid because the signing key has not changed. An attacker who has captured a session cookie through any means retains full authenticated access to the server regardless of subsequent password changes. This affects deployments using password-based authentication, particularly shared or public-facing servers where credential rotation is expected to revoke existing sessions. This issue has been fixed in version 2.18.0. | |
| CVE-2025-4407 | Med | 0.44 | 6.7 | 0.00 | Jun 30, 2025 | Insufficient Session Expiration vulnerability in ABB Lite Panel Pro.This issue affects Lite Panel Pro: through 1.0.1. | |
| CVE-2026-22706 | Med | 0.42 | 6.5 | 0.00 | May 14, 2026 | Strapi is an open source headless content management system. In Strapi versions prior to 5.33.3, changing or resetting a user's password did not invalidate the user's existing refresh-token sessions by default. The refresh-token invalidation step in the users-permissions and admin authentication controllers was conditional on a caller-supplied `deviceId`. When a password change or reset request did not include a `deviceId`, no refresh tokens were revoked, leaving every prior session active. An attacker who had previously obtained a refresh token could continue minting new access tokens after the legitimate user reset their password, allowing persistent unauthorized access for the lifetime of the refresh token (up to 30 days by default). Rotating credentials no longer terminated an active attacker session, defeating password reset as a containment measure. The patch in version 5.33.3 invalidates all refresh tokens associated with the user on every password change and password reset, regardless of whether a `deviceId` is supplied. A new device-scoped session is then issued to the caller as part of the response. | |
| CVE-2026-5545 | Med | 0.42 | 6.5 | 0.00 | May 13, 2026 | libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1... | |
| CVE-2026-40587 | Med | 0.42 | 6.5 | 0.00 | Apr 21, 2026 | blueprintUE is a tool to help Unreal Engine developers. Prior to 4.2.0, when a user changes their password via the profile edit page, or when a password reset is completed via the reset link, neither operation invalidates existing authenticated sessions for that user. A server-side session store associates userID → session; the current password change/reset flow updates only the password column in the users table and does not destroy or mark invalid any active sessions. As a result, an attacker who has already compromised a session retains full access to the account indefinitely — even after the legitimate user has detected the intrusion and changed their password — until the session's natural expiry time (configured as SESSION_GC_MAXLIFETIME, defaulting to 86400 seconds / 24 hours, with SESSION_LIFETIME=0 meaning persistent until browser close or GC, whichever is later). This vulnerability is fixed in 4.2.0. | |
| CVE-2025-4677 | Med | 0.42 | 6.5 | 0.00 | Jan 7, 2026 | Insufficient Session Expiration vulnerability in ABB WebPro SNMP Card PowerValue, ABB WebPro SNMP Card PowerValue UL.This issue affects WebPro SNMP Card PowerValue: through 1.1.8.K; WebPro SNMP Card PowerValue UL: through 1.1.8.K. | |
| CVE-2024-46040 | Med | 0.42 | 6.5 | 0.00 | Oct 7, 2024 | IoT Haat Smart Plug IH-IN-16A-S IH-IN-16A-S v5.16.1 suffers from Insufficient Session Expiration. The lack of validation of the authentication token at the IoT Haat during the Access Point Pairing mode leads the attacker to replay the Wi-Fi packets and forcefully turn off the access point after the authentication token has expired. | |
| CVE-2017-1000136 | Med | 0.42 | 6.5 | 0.00 | Nov 3, 2017 | Mahara 1.8 before 1.8.6 and 1.9 before 1.9.4 and 1.10 before 1.10.1 and 15.04 before 15.04.0 are vulnerable to old sessions not being invalidated after a password change. | |
| CVE-2017-1000135 | Med | 0.42 | 6.5 | 0.00 | Nov 3, 2017 | Mahara 1.8 before 1.8.7 and 1.9 before 1.9.5 and 1.10 before 1.10.3 and 15.04 before 15.04.0 are vulnerable as logged-in users can stay logged in after the institution they belong to is suspended. | |
| CVE-2017-1000131 | Med | 0.42 | 6.5 | 0.00 | Nov 3, 2017 | Mahara 15.04 before 15.04.8 and 15.10 before 15.10.4 and 16.04 before 16.04.2 are vulnerable to users staying logged in to their Mahara account even when they have been logged out of Moodle (when using MNet) as Mahara did not properly implement one of the MNet SSO API functions. | |
| CVE-2025-66483 | Med | 0.41 | 6.3 | 0.00 | Apr 1, 2026 | IBM Aspera Shares 1.9.9 through 1.11.0 does not invalidate session after a password reset which could allow an authenticated user to impersonate another user on the system. | |
| CVE-2025-3930 | Med | 0.41 | — | 0.00 | Oct 16, 2025 | Strapi uses JSON Web Tokens (JWT) for authentication. After logout or account deactivation, the JWT is not invalidated, which allows an attacker who has stolen or intercepted the token to freely reuse it until its expiration date (which is set to 30 days by default, but can be changed). The existence of /admin/renew-token endpoint allows anyone to renew near-expiration tokens indefinitely, further increasing the impact of this attack. This issue has been fixed in version 5.24.1. | |
| CVE-2024-35220 | Hig | 0.41 | 7.4 | 0.00 | May 21, 2024 | @fastify/session is a session plugin for fastify. Requires the @fastify/cookie plugin. When restoring the cookie from the session store, the `expires` field is overriden if the `maxAge` field was set. This means a cookie is never correctly detected as expired and thus expired sessions are not destroyed. This vulnerability has been patched 10.8.0. | |
| CVE-2024-31999 | Hig | 0.41 | 7.4 | 0.00 | Apr 10, 2024 | @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. | |
| CVE-2026-1842 | Med | 0.40 | — | 0.00 | Feb 20, 2026 | HyperCloud versions 2.3.5 through 2.6.8 improperly allowed refresh tokens to be used directly for resource access and failed to invalidate previously issued access tokens when a refresh token was used. Because refresh tokens have a significantly longer lifetime (default one year), an authenticated client could use a refresh token in place of an access token to maintain long-term access without token rotation. Additionally, old access tokens remained valid after refresh, enabling concurrent or extended use beyond intended session boundaries. This vulnerability could allow prolonged unauthorized access if a token is disclosed. | |
| CVE-2024-56413 | Med | 0.40 | 6.1 | 0.00 | Jan 2, 2025 | Missing session invalidation after user deletion. The following products are affected: Acronis Cyber Protect 16 (Windows) before build 39169. | |
| CVE-2025-12624 | Med | 0.39 | 6.0 | 0.00 | Apr 16, 2026 | Active access tokens are not revoked or invalidated when a user account is locked within WSO2 Identity Server. This failure to enforce revocation allows previously issued, valid tokens to remain usable, enabling continued access to protected resources by locked user accounts. The security consequence is that a locked user account can maintain access to protected resources through the use of existing, unexpired access tokens. This creates a security gap where access control policies are bypassed, potentially leading to unauthorized data access or actions until the tokens naturally expire. | |
| CVE-2026-34828 | Hig | 0.39 | 7.1 | 0.00 | Apr 2, 2026 | listmonk is a standalone, self-hosted, newsletter and mailing list manager. From version 4.1.0 to before version 6.1.0, a session management vulnerability allows previously issued authenticated sessions to remain valid after sensitive account security changes, specifically password reset and password change. As a result, an attacker who has already obtained a valid session cookie can retain access to the account even after the victim changes or resets their password. This weakens account recovery and session security guarantees. This issue has been patched in version 6.1.0. | |
| CVE-2026-5376 | Med | 0.38 | 5.9 | 0.00 | Apr 7, 2026 | An issue that could prevent session inactivity timeouts from triggering due to automatic page reloading has been resolved. This is an instance of CWE-613: Insufficient Control of Resources After Expiration or Release, and has an estimated CVSS score of CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N (5.9 Medium). This issue was fixed in version 4.0.260203.0 of the runZero Platform. |