HCL AION contains a vulnerability where user sessions do not expire after a sufficient period of inactivity. This could allow an unattended authenticated session to be accessed by another person with access to the same system, potentially leading to unauthorized viewing of information or actions performed on behalf of the user. The issue is classified as insufficient session expiration and has a low severity rating.
Ericsson CodeChecker versions prior to 6.29.3 have a session management vulnerability where logout does not fully invalidate session tokens when multiple API worker processes are used. Each worker maintains its own in-memory session cache, so tokens remain valid in other workers until expiration. This allows an attacker with a captured token to impersonate a user after logout.
Authentication Bypass by Capture-replay in ExternalLoginKeysManager in Apache OFBiz 24.09 before 24.09.08 on all platforms allows a remote unauthenticated attacker who captures a live externalLoginKey value to obtain a complete, cookie-free, reusable session as the user who issued it, in every webapp that user can reach, because checkExternalLoginKey runs as a global preprocessor ahead of both the CSRF and authentication checks and accepts the key as a bearer credential that is never bound to a client, never expires, and is not invalidated after use, while the framework itself both appends live keys to every cross-webapp link it renders and, via WidgetWorker's unvalidated inter-app link target, lets an authenticated user's key be attached to an attacker-chosen absolute URL and delivered directly to the attacker's own server. Users are recommended to upgrade to version 24.09.08, which fixes this issue.
The refresh token grant type in WSO2 products fails to re-validate account status before issuing new access tokens. This weakness allows an attacker to obtain valid access tokens for user accounts even after they have been blocked by the user store, bypassing account lockout mechanisms.
This vulnerability can lead to unauthorized access to user accounts and their associated resources. Attackers can leverage this to perform actions on behalf of blocked users, potentially leading to privilege escalation or data exfiltration depending on the permissions of the compromised account.
Insufficient session expiration in Apache Wicket.
org.apache.wicket.protocol.ws.WebSocketSettings#newWebSocketRequest() wraps the WebSocket upgrade request in an org.apache.wicket.protocol.ws.api.ServletRequestCopy, which is kept for the life of the connection and used to build the request for every frame that arrives on it. Copying the request is deliberate and is documented as such, because the container recycles the upgrade request once the handshake is over. The container session is copied along with it, into an org.apache.wicket.protocol.ws.api.HttpSessionCopy holding the session attributes as they stood when the connection was opened. That second copy is not necessary, because a session, unlike a request, is not discarded at the end of a request. Every frame afterwards resolves its Wicket session through ISessionStore#lookup(), which reads it out of the copy, so the connection is detached from the live container session for as long as it stays open.
Ending the session through the container therefore does not end the connection. After an idle timeout, an HttpSession#invalidate() call made from a filter or from a security framework, a container-managed logout, or a session replacement, the connection goes on resolving the org.apache.wicket.Session instance that existed when it was opened, together with that session's attributes and, for applications built on wicket-auth-roles, the signed-in state held on that same instance, so an authorization decision taken inside a WebSocket callback is taken against an identity that has already been revoked. The copy is also what the connection writes through: a Session#invalidateNow() issued from inside a WebSocket callback invalidates the copy and leaves the container session valid, and session attributes set over the connection are written to the copy rather than to the session.
An application is affected where it uses Wicket's native WebSocket support on pages or shared resources that require an authenticated session, and where sessions are ended by the container rather than by Wicket. Session#invalidateNow(), and AuthenticatedWebSession#invalidate() and #signOut() which call it, remain effective for a WebSocketBehavior on a page: they clear the page manager, and the connection can then no longer resolve the page it was opened for. A WebSocketResource is not limited in that way, because a frame naming a resource is served against a throwaway page and never consults the page manager, so such a connection outlives Wicket's own sign-out as well. Some containers close WebSocket connections themselves when the HTTP session they were opened under is destroyed, in which case the connection ends regardless; that is a property of the container rather than of Wicket. Applications that do not use the native WebSocket support are not affected.
This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Older, unsupported releases from 6.0.0 onwards are also affected. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
Coop is an open source review and moderation tool from ROOST. Prior to 1.0.2, `resetPasswordForToken` updates the password row without invalidating database-backed sessions. An attacker who has acquired a password and established a session retains access even after the legitimate user resets the password, leaving the compromised account under attacker control until the session expires at its `30-day` maximum age. This issue is fixed in version 1.0.2.
pgAdmin 4 did not invalidate a user's existing sessions when their password changed, either through the user's own change password dialog or through an administrator resetting it in User Management. A session established before the change, for example on another device or by someone who had obtained the old password or a session cookie, therefore stayed logged in after the change, which is the step a user or administrator takes precisely to cut such access off. It remained usable until it expired.
The fix rotates the user's session identifier (fs_uniquifier) whenever the password is changed, so every other session of that user is logged out. The session that made the change is logged in again and keeps its database connections. Saved server passwords, including those for shared servers, are re-encrypted under the new key; any that cannot be decrypted are cleared and the user is told. If re-encryption fails, the sessions are still revoked and the saved passwords are cleared rather than the change failing.
This issue affects pgAdmin 4: before 9.19.
CVE-2026-118665 is a high-severity vulnerability in the ardatan graphql-tools legacy WebSocket executor package prior to version 1.1.36. It involves insufficient session expiration where sensitive connection parameters from a previous request are retained and reused improperly, potentially allowing unauthorized authentication as a previous user. This issue is fixed in version 1.1.36.
CVE-2026-6647 is a vulnerability in WSO2 Identity Server affecting deployments with a case-insensitive user store and a case-sensitive identity database. This mismatch causes OAuth token revocation to fail for usernames with mixed-case characters, allowing tokens to remain valid when they should be revoked. An attacker with a valid token for such a username can continue unauthorized actions until token expiry, bypassing intended access controls. The issue affects versions 7.2.0 up to but not including 7.2.0.21 and 7.0.385 up to but not including 7.0.385.17. Fixes are available in versions 7.2.0.21 and 7.0.385.17. The CVSS 3.1 score is 7.4 (high severity).
CVE-2026-3583 is a vulnerability in WSO2 API Manager where the OAuth2 token introspection cache does not immediately invalidate a token after revocation when the allowed_scopes configuration is enabled. This can cause a revoked access token to be temporarily re-issued to clients until the cache entry is cleared. Although the re-issued token is not valid for API authorization, affected users may experience disruption in obtaining new valid tokens during this cache lifetime.
@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.
The twofactor_gauthenticator plugin for Roundcube suffers from insufficient session expiration after failed two-factor authentication attempts. This vulnerability allows an attacker to maintain a session despite a logout redirect, potentially enabling brute force attacks on the second-factor code if the user's password is compromised. The issue was addressed in a specific commit.
CVE-2026-95663 is an insufficient session expiration vulnerability in the Apache Camel Keycloak component affecting versions from 4.16.0 before 4.18.5 and from 4.19.0 before 4.22.2. When token introspection is enabled, cached introspection results may allow expired tokens to be accepted for up to the cache TTL, potentially permitting continued use of recently expired tokens. The issue does not allow token forgery or privilege escalation and is rated medium severity. Fixed in Apache Camel versions 4.18.5 and 4.22.2.
CVE-2026-96616 is a vulnerability in Kiloview E3 Firmware where authentication tokens issued by the device's web management interface have excessively long expiration times, effectively making them non-expiring. This allows tokens obtained through interception or device compromise to remain valid for a prolonged period, increasing the risk of unauthorized access. The issue affects versions prior to 1.30 and has been fixed in version 1.30.
CVE-2026-54238 is a vulnerability in Supabase Realtime versions prior to 2.103.1 where expired JWT tokens with the exp claim encoded as a JSON string are incorrectly accepted by the REST broadcast endpoints. This allows an unauthenticated attacker to broadcast realtime messages to subscribers. The issue has been fixed in version 2.103.1.
A vulnerability in django-rest-framework versions 3.12.0 through 3.18.1 causes TokenProxy.delete() to fail silently when attempting to revoke tokens. This occurs because the deletion query uses the proxy's user-id primary key instead of the token-string primary key, resulting in zero deletions without error. Consequently, tokens may remain active and continue authenticating despite apparent revocation. The issue is fixed in version 3.18.2.
CVE-2025-0326 is a vulnerability in WSO2 Identity Server where access tokens for sub-organization users are not invalidated during sensitive account management operations such as password resets, role changes, or sub-organization disablement. This can allow previously issued tokens to remain active despite administrative changes that should revoke access. Exploitation requires that these tokens be exposed to malicious actors. The issue affects specific versions of WSO2 Identity Server and has been fixed in later releases.
IBM Storage TS4500 Library 1.1.1.6 through 1.12.0.3 does not invalidate session after a logout which could allow an authenticated user to impersonate another user on the system.
CVE-2025-36252 is a vulnerability in IBM Storage TS4500 Library versions 1.1.1.6 through 1.12.0.3. The issue involves insufficient session expiration, where sessions are not invalidated properly. This flaw could allow an authenticated user to impersonate another user on the system.
WSO2 API Control Plane versions prior to fixed releases do not revoke tokens associated with user sessions upon session termination when token binding validation is enabled and the 'Revoke token upon user logout' option is disabled. This allows session-bound tokens to remain valid after logout, potentially enabling unauthorized access to resources.