Home / CVEs
CVE Database
Published vulnerabilities with severity, known exploitation and official sources.
CVE-2026-64829
High · 7.4
CWE-613 Jul 22, 2026
Question2Answer 1.8.8 Session Fixation via Forgot-Password Flow
Question2Answer through 1.8.8 contains a session invalidation vulnerability that allows attackers with a previously obtained remember-me cookie to retain authenticated access by exploiting the forgot-password reset flow's failure to clear the sessioncode field in qa-include/app/users-edit.php. While the normal password-change flow in qa-include/pages/account.php explicitly clears the sessioncode to invalidate persistent qa_session cookies, the forgot-password handler qa_finish_reset_user() omits this step, allowing any valid persistent cookie issued before the reset to continue authenticating the account after the password reset completes.
CVE-2026-56583
Low · 3.1
CWE-613 Jul 21, 2026
HCL MyCloud was affected with Concurrent Login Vulnerability.
HCL MyCloud was affected with Concurrent Login Vulnerability. It may increase the risk of unauthorized access, session hijacking, and account misuse.
CVE-2026-63753
Medium · 4.3
CWE-613 Jul 20, 2026
SurrealDB before 3.1.0 Authentication Bypass via LIVE Query
SurrealDB before 3.1.0 fails to refresh authentication state in LIVE SELECT subscriptions when session state changes. Attackers can continue receiving real-time notifications under revoked or expired session credentials until the connection closes.
CVE-2026-16206
Medium · 6.3
CWE-613 Jul 19, 2026
django-oauth django-oauth-toolkit oauth2_validators.py _load_id_token session expiration
A security vulnerability has been detected in django-oauth django-oauth-toolkit 3.3.0. This issue affects the function _load_id_token of the file oauth2_provider/oauth2_validators.py. The manipulation leads to session expiration. The attack can be initiated remotely. The project was informed of the problem early through an issue report but has not responded yet.
CVE-2026-63175
High · 7.1
CWE-613 Jul 15, 2026
Cross-Capture Session Data Leakage Due to Shared Mutable State in Looklyloo - PlaywrightCapture
PlaywrightCapture stored capture-specific configuration and runtime data as mutable class-level variables rather than instance-level variables. Consequently, multiple Capture objects running within the same Python process could share state, including HTTP headers, cookies, browser storage, HTTP credentials, proxy configuration, user-agent settings, geolocation information, and captured request data.
In a multi-user or concurrent deployment, information supplied during one capture could therefore persist and be reused by a subsequent or parallel capture. This could result in the disclosure of authentication cookies, credentials, browser storage, or captured request data belonging to another user. It could also cause requests to be performed with another capture's authentication context, headers, or proxy configuration, potentially enabling unauthorized access to remote resources or interference with other capture operations.
The vulnerability is resolved by initializing all capture-specific settings and request data as instance variables in the Capture constructor, ensuring that state is isolated between capture operations.
CVE-2026-61452
Medium · 5.3
CWE-613 Jul 15, 2026
Grav before 2.0.4 Improper Session Invalidation JWT Access Tokens
The Grav API plugin (getgrav/grav-plugin-api) before 2.0.4 contains an improper session invalidation vulnerability where JWT access tokens are issued without a jti (JWT ID) claim and therefore cannot be revoked server-side. Unlike refresh tokens, access tokens remain valid for their full lifetime (default 1 hour) regardless of logout, password change, new token issuance, or account disablement. An attacker who has stolen an access token retains full API access until the token naturally expires.
CVE-2026-56400
Critical · 9.6
CWE-613 Jul 15, 2026
open-webui - Remote Code Execution via CORS Misconfiguration and Session Validation
open-webui before 0.3.14 contains a cross-origin resource sharing misconfiguration allowing arbitrary origins with allow_origins=* and authenticated requests to the /api/v1/functions endpoint. Attackers can execute arbitrary code on the openwebui instance by crafting malicious cross-site requests from attacker-controlled websites when an admin user visits them.
CVE-2026-48329
Low · 2.7
CWE-613 Jul 14, 2026
ColdFusion | Insufficient Session Expiration (CWE-613)
ColdFusion is affected by an Insufficient Session Expiration vulnerability that could result in a Security feature bypass. A high-privileged attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction.
CVE-2026-44383
High · 7.5
CWE-613 Jul 10, 2026
Hydro-Québec Le Circuit Electrique charging station backend Insufficient Session Expiration
Multiple connections to the backend using the same charging station ID
are allowed, which could allow an attacker to deploy multiple instances
of malicious OCPP clients to overwhelm the backend.
CVE-2026-56665
Medium · 4.2
CWE-613 Jul 10, 2026
ZITADEL: Missing Token Expiration (`exp`) Validation in JWT IdP Provider
ZITADEL is an open source identity management platform. Prior to 3.4.12 and 4.15.2, ZITADEL is an open source identity management platform. From 3.0.0-rc.1 through 3.4.11 and from 4.0.0-rc.1 through 4.15.1, ZITADEL's external JWT Identity Provider validation in internal/idp/providers/jwt/session.go skips expiration handling when an incoming token omits the exp claim, allowing a token from a trusted issuer to be treated as valid without an automatic expiration window. This issue is fixed in versions 3.4.12 and 4.15.2.
CVE-2026-56664
Medium · 4.2
CWE-613 Jul 10, 2026
ZITADEL: Missing Token Lifecyle Validation (`exp` and `iat`) in JWT IdP Provider
ZITADEL is an open source identity management platform. Prior to 3.4.12 and 4.15.2, ZITADEL's external JWT Identity Provider validation in internal/idp/providers/jwt/session.go skips the maximum token age freshness check when an incoming token omits the iat claim, allowing arbitrarily old tokens from a trusted issuer to pass authentication. This issue is fixed in versions 3.4.12 and 4.15.2.
CVE-2026-59219
High · 7.1
CWE-613 Jul 9, 2026
Open WebUI: Realtime endpoints accept Redis-revoked JWTs after signout/backchannel logout
Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 before 0.10.0 with Redis configured, Socket.IO connect, user-join, join-channels, join-note, and the terminal websocket first-message authentication used decode_token without the Redis-backed is_valid_token revocation check, allowing revoked JWTs to continue authenticating realtime connections. This issue is fixed in version 0.10.0.
CVE-2026-49229
High · 8.3
CWE-613 Jul 7, 2026
Actual: Disabled OpenID users keep access through existing session tokens
Actual is a local-first personal finance app. Prior to 26.6.0, in OpenID multi-user mode, disabling a user only blocks future OpenID login for that identity, while existing Actual session tokens for the disabled user remain valid. The shared session validation path accepts any existing token row that has not expired without checking whether the associated user is still enabled, allowing a disabled user to continue calling authenticated server endpoints. This issue is fixed in version 26.6.0.
CVE-2026-42172
Low · 3.1
CWE-613 Jul 7, 2026
Coolify: Sanctum API Tokens Have No Expiration — Leaked Tokens Grant Permanent Access
Coolify is an open-source and self-hostable tool for managing servers, applications, and databases. Prior to 4.0.0-beta.474, Sanctum API tokens did not expire, allowing a leaked token to retain access indefinitely until manually revoked. This issue is fixed in version 4.0.0-beta.474.
CVE-2026-43918
High · 8.7
CWE-613 Jul 6, 2026
Suspended or inactive FOSSBilling accounts can retain or regain access through existing sessions, API tokens, and password reset flows
FOSSBilling is a free, open-source billing and client management system. Prior to version 0.8.0, when a client or staff/admin account is suspended or marked inactive, existing authenticated sessions are not invalidated. The session identity loaders in src/di.php (loggedin_client and loggedin_admin) only reject sessions if the backing account record no longer exists in the database. They do not verify that the account's status is still active. This allows a suspended or deactivated user to retain full access until their session naturally expires. This issue has been fixed in version 0.8.0.
CVE-2026-46455
Critical · 9.8
CWE-613 Jul 6, 2026
Apache Camel: Camel-Keycloak: The access-token validity window is not verified because the IS_ACTIVE check is missing from the TokenVerifier, allowing expired tokens to be accepted
Insufficient Session Expiration vulnerability in Apache Camel Keycloak Component.
The camel-keycloak security helper KeycloakSecurityHelper.parseAndVerifyAccessToken builds a Keycloak TokenVerifier using withChecks(...) with only the subject-exists check and the realm-URL (issuer) check. Keycloak's TokenVerifier.withChecks(...) appends to an initially empty check list - the upstream default checks are installed only when withDefaultChecks() is called - so the built-in IS_ACTIVE predicate, which validates the token's exp (expiration) and nbf (not-before) claims, is never applied. As a result the helper verifies the token signature, subject and issuer but does not enforce the token's validity window: an access token that is expired, or not yet valid, is accepted as valid. Routes that rely on this helper to authenticate inbound requests therefore accept access tokens that are outside their intended lifetime.
This issue affects Apache Camel: from 4.18.0 before 4.18.3, from 4.19.0 before 4.21.0.
Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. The fix makes KeycloakSecurityHelper.parseAndVerifyAccessToken include the TokenVerifier.IS_ACTIVE check so that expired or not-yet-valid access tokens are rejected, aligning the helper with Keycloak's default check set. For deployments that cannot upgrade immediately, enforce token expiration outside the helper - for example validate the access token's exp/nbf claims in the route before trusting it, keep Keycloak access-token lifetimes short, and ensure any upstream gateway or resource server also validates the token validity window.
CVE-2026-14725
Medium · 6.3
CWE-613 Jul 5, 2026
SourceCodester Online Boat Reservation System session expiration
A vulnerability was identified in SourceCodester Online Boat Reservation System 1.0. Affected by this vulnerability is an unknown functionality. Such manipulation leads to session expiration. It is possible to launch the attack remotely. The exploit is publicly available and might be used.
CVE-2025-36359
Medium · 6.5
CWE-613 Jun 30, 2026
IBM DevOps Loop is susceptible to an Insufficient Session Expiration vulnerability.
IBM DevOps Automation 1.0.1 and IBM DevOps Loop 1.0.2 does not invalidate session IDs after expiration which could allow an authenticated user to impersonate another user on the system.
CVE-2026-54479
High · 7.3
CWE-613 Jun 25, 2026
EVoke Systems EVoke CSMS Insufficient Session Expiration
The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers. This vulnerability may allow unauthorized users to authenticate as other users or enable a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.
CVE-2025-71335
High · 8.1
CWE-613 Jun 25, 2026
Flowise - Session Invalidation Failure After Password Change
Flowise before 3.0.10 (affected versions 3.0.7 and earlier) fails to invalidate existing sessions and session tokens after a user changes their password. An attacker who already holds an active session, for example via a stolen session token or a device left logged in, remains authenticated as the legitimate user even after the user rotates their credentials, undermining the security purpose of the password change.
CVE-2026-9705
Medium · 6.5
CWE-613 Jun 25, 2026
Keycloak: keycloak: attacker can re-enable and take over disabled clients via registration access token
A flaw was found in Keycloak's client registration service. A remote attacker, possessing a previously issued Registration Access Token (RAT), could exploit this vulnerability to re-enable a client that an administrator had explicitly disabled. This bypasses security controls, allowing the attacker to reset the client's secret and potentially regain privileged API access. The primary impact includes unauthorized information disclosure and potential integrity compromise.
CVE-2026-49277
Low · 2.3
CWE-613 Jun 24, 2026
Rocket.Chat: OAuth access and refresh tokens remain valid after account deactivation
Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, and 7.10.12, Rocket.Chat does not revoke OAuth bearer or refresh tokens when a user is deactivated. A deactivated user can continue using an existing OAuth access token, and can also mint a fresh access token from an existing refresh token. This vulnerability is fixed in 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, and 7.10.12.
CVE-2026-45757
Low · 2.3
CWE-613 Jun 24, 2026
Rocket.Chat: users.deactivateIdle` deactivates accounts without revoking existing login tokens
Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, and 7.10.12, Rocket.Chat allows users deactivated through users.deactivateIdle to keep using already-issued login tokens. A user that an administrator has marked inactive for idleness can still access authenticated REST endpoints with the old token. This vulnerability is fixed in 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, and 7.10.12.
CVE-2026-53928
Medium · 6.3
CWE-613 Jun 23, 2026
NocoDB: Refresh Tokens Persist Through Password Recovery
NocoDB is software for building databases as spreadsheets. Prior to 2026.05.1, a stolen refresh token survived a password-forgot flow and could be used to mint fresh JWTs even after the user reset their password. passwordChange and passwordReset deleted the user's refresh tokens, but passwordForgot only rotated token_version and revoked OAuth tokens — it did not call UserRefreshToken.deleteAllUserToken(user.id). An attacker holding a captured refresh cookie could still exchange it for a new access token after the victim triggered the recovery flow. This vulnerability is fixed in 2026.05.1.
CVE-2026-53926
Medium · 6.3
CWE-613 Jun 23, 2026
NocoDB: OAuth Tokens Persist Through Security Events
NocoDB is software for building databases as spreadsheets. Prior to 2026.05.1, revokeAllOAuthTokensByUser in the users service is an empty stub being called from passwordChange, passwordForgot, and passwordReset. OAuth access and refresh tokens were not revoked when the user changed, reset, or recovered their password, leaving an attacker-issued OAuth grant valid after the user believed they had locked the attacker out. This vulnerability is fixed in 2026.05.1.