Overview 589 matches · 41 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
589matches
41in Waratek scope7.0%
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
41
7.0%
Outside Waratek scope
3
0.5%
Not applicable
545
92.5%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
589
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
589
100.0%
split by
peak 212 / year
20131
Not applicable1
High1
not blocked1
No public exploit1
20141
Not applicable1
Medium1
not blocked1
No public exploit1
20150
20160
201712
No exploit published2
Not applicable10
Critical2
High4
Medium6
not blocked12
No public exploit12
201816
Not applicable16
Critical1
High7
Medium8
not blocked16
No public exploit16
201922
No exploit published2
Not applicable20
Critical4
High10
Medium8
not blocked22
No public exploit22
202048
No exploit published2
Outside Waratek scope1
Not applicable45
Critical5
High21
Medium19
Low3
not blocked48
No public exploit48
202151
No exploit published3
Outside Waratek scope1
Not applicable47
Critical14
High17
Medium18
Low2
not blocked51
No public exploit51
202246
No exploit published1
Outside Waratek scope1
Not applicable44
Critical9
High17
Medium17
Low3
not blocked46
No public exploit46
202343
No exploit published5
Not applicable38
Critical8
High21
Medium12
Low2
not blocked43
No public exploit43
202464
No exploit published3
Not applicable61
Critical9
High27
Medium26
Low2
not blocked64
No public exploit64
202573
No exploit published3
Not applicable70
Critical6
High24
Medium33
Low10
not blocked73
No public exploit73
2026212
No exploit published20
Not applicable192
Critical27
High50
Medium103
Low31
Unknown1
not blocked212
No public exploit212
2014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-92738 | Medium | 2026-11-13 | Not applicable | No public exploit | Vault's Login MFA feature did not consistently enforce the lifetime of pending two-phase login requests. This may allow a user who previously completed the first authentication factor to complete MFA and obtain a Vault token after the pending request should have expired, including after the user's primary credential has been rotated. This vulnerability (CVE-2026-92738) is fixed in Vault Community Edition 2.2.2 and Vault Enterprise 2.2.2, 1.21.14, and 1.19.26. |
| CVE-2026-128335 | Low | 2026-11-13 | Not applicable | No public exploit | Contao 4.6.0 before 5.3.54, 5.4.0-RC1 before 5.7.17, and 6.0.0-RC1 before 6.0.6 fails to invalidate existing user sessions when two-factor authentication is enabled or disabled. Because Contao\User::isEqualTo() and serialized session data omit two-factor state, attackers already holding a session keep it after the owner changes 2FA settings. |
| CVE-2026-128330 | Low | 2026-11-13 | Not applicable | No public exploit | Miniflux before 2.3.5 contains an insufficient session expiration vulnerability that allows attackers to retain account access because password changes do not revoke existing web sessions. Attackers holding a leaked password or copied session cookie keep access for up to 30 days, reading integration credentials, creating API keys, or registering passkeys. |
| CVE-2026-128030 | High | 2026-11-13 | Not applicable | No public exploit | OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains an insufficient session expiration vulnerability because Mage_Api_Model_Session::_renewBySessId() never checks api_user.is_active and REST OAuth authorization never checks whether the admin user is active. Attackers holding an existing SOAP/XML-RPC session or OAuth access token retain API access after deactivation or API key rotation, reading and modifying customer, order and catalog data. |
| CVE-2026-126453 | High | 2026-11-13 | Not applicable | No public exploit | OpenEMR before 8.5.0 contains an inverted comparison in Document::has_expired() that causes the FHIR Binary download endpoint to treat time-limited PHI documents as unexpired after their one-hour lifetime. Authenticated users still authorized for a Binary/{id} resource can download expired bulk export NDJSON files and $docref CCDs indefinitely. |
| CVE-2026-126427 | Medium | 2026-11-13 | Not applicable | No public exploit | OpenEMR before 8.5.0 contains a session expiration vulnerability that prevents automatic logoff because the Eye Exam form's read-only poll omits skip_timeout_reset. Attackers with physical access to an unattended workstation can use the still-active session to view patient health information, since update_READONLY() resets the idle timer every 15 seconds. |
| CVE-2026-126076 | Medium | 2026-11-10 | Not applicable | No public exploit | Action Pack is a framework for handling and responding to web requests. Prior to 8.1.4.1 and 8.0.5.2, ActionDispatch::Session::CacheStore writes a session back to the cache at the end of each request that loaded it, without checking that the session's cache entry still exists. When a concurrent request destroys the session, through reset_session on logout or by deleting its cache entry on the server, a request that loaded the session earlier and finishes later restores it under its original session ID. Logout and server-side revocation could therefore fail to end a session, and an attacker who holds a stolen session cookie could keep that session valid across the victim's logout. Applications that use config.session_store :cache_store are affected, with any cache backend. ActionDispatch::Session::CookieStore is not affected, nor is ActionDispatch::Session::MemCacheStore with Dalli 4.0.0 or later, whose session store does not write back a session that was deleted. This issue is fixed in versions 8.1.4.1 and 8.0.5.2. |
| CVE-2026-111243 | Unknown | 2026-11-10 | No exploit published | No public exploit | A negative MicroProfile JWT clock skew setting is not rejected and disables validation of the token expiration and other time-based claims. In such configurations, an attacker in possession of an expired token can still authenticate with it. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue. |
| CVE-2026-123813 | High | 2026-11-09 | Not applicable | No public exploit | pyLoad is a free and open-source download manager written in Python. Prior to 0.5.0b3.dev102, pyLoad does not invalidate existing Flask sessions when an administrator changes a user's permissions or password through /api/set_user_permission or /api/change_password. Api.set_user_permission and Api.change_password update the database, but session authorization continues to use role and permission values copied at login by set_session in webui/app/helpers.py. A user can therefore retain revoked privileges or continue using a session established with an old password for the configured session lifetime. API-key authentication is not affected because that path rereads user data from the database. This issue is fixed in version 0.5.0b3.dev102. |
| CVE-2026-123804 | Medium | 2026-11-09 | Not applicable | No public exploit | SuperTokens Core is an open source authentication server. From 7.0.0 until 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, createNewSession can resolve a primary user before unlinkAccounts detaches a login method and then insert the session after unlink has enumerated and revoked the existing sessions. A user who controls the linked login method can exploit this race to retain a signed, database-backed, refreshable session as the former primary identity after that method is unlinked; the session persists until expiry or explicit revocation. This issue is fixed in versions 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1. |
| CVE-2026-123799 | High | 2026-11-09 | Not applicable | No public exploit | SuperTokens Core is an open source authentication server. From 11.0.0 until 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, and 12.1.2, Dashboard.isValidUserSession treats any stored session row as valid without comparing DashboardSessionInfo.expiry to the current time. DashboardQueries.getSessionInfoWithSessionId also selects by app and session identifier without an expiry predicate, leaving the periodic DeleteExpiredDashboardSessions cleanup as the only expiration enforcement. An attacker who obtains a dashboard administrator session after its 30-day lifetime can continue using POST /recipe/dashboard/session/verify until the row is removed, and frequent Core restarts can prevent the 12-hour cleanup sweep from running. The stale session retains full dashboard read and write access, but the flaw does not provide a way to guess or acquire the random session identifier. This issue is fixed in versions 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, and 12.1.2. |
| CVE-2026-113508 | High | 2026-11-09 | Not applicable | No public exploit | Apache Airflow's logout endpoint attempted to revoke the presented token on the server, but any failure during revocation was silently ignored and logout still reported success. When the auth manager redirects logout to an external logout URL (for example the FAB or Keycloak auth managers), server-side revocation is the only thing that invalidates the Airflow token; it failed on database errors and, reliably, for tokens from an external issuer accepted via `[api_auth] trusted_jwks_url` whose token identifier is longer than 32 characters. Anyone holding a copy of a user's token from before logout could keep using it against the Airflow API until it expired. Users are advised to upgrade to apache-airflow 3.4.0 or later. |
| CVE-2026-106466 | High | 2026-11-09 | Not applicable | No public exploit | The JWT Auth WordPress plugin through 3.0.2 does not invalidate previously issued refresh tokens when a user changes or resets their password or removes a connected device, allowing an attacker who obtained a refresh token before such an event to keep issuing valid access tokens and retain authenticated access to the account, up to Administrator. |
| CVE-2026-123598 | Medium | 2026-11-08 | Not applicable | No public exploit | The validating recursor in Hickory DNS hickory-recursor 0.25.0 through 0.26.0-alpha.1, hickory-resolver 0.26.0-alpha.1 before 0.26.2, and hickory-net 0.26.0-beta.1 before 0.26.2 caches DNSSEC-bogus answers using the untrusted, attacker-supplied record TTL (capped at 24 hours) instead of a short validation-failure TTL. A remote attacker who spoofs a single authoritative response with an invalid signature and a long TTL can keep the bogus result cached for up to 24 hours. |
| CVE-2026-123597 | Medium | 2026-11-08 | Not applicable | No public exploit | Hickory DNS hickory-proto 0.25.0-alpha.1 through 0.26.0-alpha.1 and hickory-net before 0.26.2 contain a logic bug in DnssecDnsHandle's DS-fetch path that caches transient DS lookup errors as Bogus DNSSEC validation verdicts. An attacker who induces a SERVFAIL, REFUSED, or timeout response to a child-zone DS sub-query causes the validator to return SERVFAIL for all names under that zone until the cache entry's TTL expires. |
| CVE-2026-123493 | Medium | 2026-11-08 | Not applicable | No public exploit | Vikunja from 2.4.0 before 2.7.1 contains an authentication bypass vulnerability that allows disabled or locked users to retain access through API tokens owned by their bot users. Because token validation only checks the bot's own status, attackers holding pre-minted bot tokens can keep reading and modifying shared projects via the HTTP API, CalDAV, MCP and feeds. |
| CVE-2026-66986 | Low | 2026-11-06 | Not applicable | No public exploit | HCL AION is affected by a vulnerability where user sessions did not expire after a sufficient period of inactivity. An unattended authenticated session could be used by another person with access to the same system to view information or perform actions on behalf of the user, potentially resulting in unintended behavior or security impact under certain conditions. |
| CVE-2026-123292 | Low | 2026-11-06 | Not applicable | No public exploit | In JetBrains Datalore before 2026.4 aPI tokens and sessions of removed or banned users remained valid |
| CVE-2026-82907 | Critical | 2026-11-05 | Not applicable | No public exploit | 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. |
| CVE-2026-95762 | Medium | 2026-11-03 | Not applicable | No public exploit | An insufficient session expiration vulnerability exists in the API of HPE Networking Fabric Composer if certain preconditions outside of the attacker's control are met. Successful exploitation could allow an authenticated administrative attacker to maintain persistent access to the affected system. |
| CVE-2026-121735 | Medium | 2026-11-03 | Not applicable | No public exploit | blueprintUE self-hosted edition before 4.3.4 contains an insufficient session expiration vulnerability that allows attackers to confirm accounts using stale tokens because UserModel::findUserIDWithConfirmedToken ignores confirmed_sent_at. Attackers who obtain an old confirmation link from a compromised mailbox, backup, or forwarded mail can activate unconfirmed accounts and evade the unconfirmed-account cleanup job. |
| CVE-2026-120340 | Low | 2026-11-02 | Not applicable | No public exploit | A weakness has been identified in mathurvishal CloudClassroom-PHP-Project. This issue affects some unknown processing of the component Global Session Handler. Executing a manipulation can lead to session expiration. The attack may be launched remotely. A high complexity level is associated with this attack. The exploitability is assessed as difficult. The exploit has been made available to the public and could be used for attacks. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases. The vendor was contacted early about this disclosure but did not respond in any way. |
| CVE-2024-9517 | Medium | 2026-11-02 | No exploit published | No public exploit | 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. |
| CVE-2026-82559 | Low | 2026-11-01 | No exploit published | No public exploit | 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. |
| CVE-2026-63400 | Low | 2026-10-30 | Not applicable | No public exploit | 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. |
| CVE-2026-119577 | High | 2026-10-30 | Not applicable | No public exploit | ArcadeDB before 26.10.2 contains an improper authorization vulnerability that allows revoked users to retain access through already-open Postgres, Bolt, MongoDB, or Redis wire-protocol connections. Attackers holding an existing connection can keep reading and writing data after deletion, grant removal, or password rotation, because executors keep a stale ServerSecurityUser. |
| CVE-2026-116251 | Low | 2026-10-30 | Not applicable | No public exploit | 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-2025-49602 | Critical | 2026-10-30 | Not applicable | No public exploit | An issue was discovered in Keyfactor EJBCA 9. When an administrator is removed from its administrator role while having a valid TLS session, EJBCA may, in certain circumstances, cache authentication for longer than the configured maximum time (default: 30 seconds), which results in the former administrator retaining access that they should no longer have. |
| CVE-2026-6647 | High | 2026-10-28 | No exploit published | No public exploit | In deployments of WSO2 Identity Server configured with a case-insensitive user store and a case-sensitive database for identity data, mismatches in username case handling can occur. This inconsistency results in OAuth token revocation operations failing to correctly identify usernames containing mixed-case characters during certain lifecycle events, preventing tokens from being invalidated. A malicious actor can exploit this vulnerability by possessing a valid access or refresh token associated with a mixed-case username. In affected configurations, these tokens may not be revoked when expected. The actor can then leverage these unrevoked tokens, before their expiry, to continue performing actions that should have been restricted, effectively bypassing intended access controls. |
| CVE-2026-3583 | Low | 2026-10-28 | No exploit published | No public exploit | When the `allowed_scopes` configuration is enabled, the OAuth2 token introspection mechanism does not immediately invalidate a token in the cache after a revocation request. This results in a scenario where an access token that was introspected immediately before a revocation request may be returned again to the client after revocation, until the relevant cache entry is cleared. The security consequence is that a revoked access token may be re-issued to the client during the cache lifetime. While the re-issued token is not treated as valid for API authorization, affected users may be unable to obtain a new valid access token until the cache is cleared, which can disrupt authentication flows. |
| CVE-2026-117499 | Low | 2026-10-27 | Not applicable | No public exploit | @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. |
| CVE-2026-116894 | Low | 2026-10-27 | Not applicable | No public exploit | REDAXO before 5.21.5 contains an insufficient session expiration vulnerability that allows attackers to retain account access by keeping the current session and stay-logged-in key valid after a password change. Attackers who obtained a user's session id or stay-logged-in cookie can keep backend access after the password change, via the cookie for up to three months. |
| CVE-2026-107146 | Medium | 2026-10-27 | Not applicable | No public exploit | The twofactor_gauthenticator plugin for Roundcube is vulnerable to session persistence after failed 2FA verification. Due to the lack of server-side session destruction, an attacker can ignore the logout redirect and keep the session alive. This may allow an attacker who obtains user's password to e.g. brute force the second-factor code. This issue was fixed in commit 4640889. |
| CVE-2026-95663 | Medium | 2026-10-26 | No exploit published | No public exploit | Insufficient Session Expiration vulnerability in Apache Camel Keycloak component. This issue affects Apache Camel: from 4.16.0 before 4.18.5, from 4.19.0 before 4.22.2. When token introspection is enabled on the camel-keycloak KeycloakSecurityPolicy (useTokenIntrospection=true), the security processor validates the access token of a request by sending it to Keycloak's OAuth 2.0 token introspection endpoint, and accepts the token while the response reports it as active. The introspection endpoint reports a token as inactive once its exp (expiration) time has passed, so on this path the active flag is what enforces token expiry. Introspection results are cached by default (introspectionCacheEnabled=true, introspectionCacheTtl=60 seconds), and both cache implementations shipped with the component, ConcurrentMapTokenCache and CaffeineTokenCache, expired an entry a fixed time after it was inserted, without bounding that lifetime by the exp claim that the cached response already carried. KeycloakSecurityProcessor in turn checked only the active flag of the result, on every path that uses introspection, and never compared exp with the current time. A response cached shortly before the token expired was therefore served to later requests carrying the same token for up to the configured time-to-live after the token's expiry, and those requests were admitted with the roles and permissions the expired token had carried, although RFC 7662, which defines token introspection, states that a response containing exp must not be cached beyond that time. The access token is supplied by the caller with each request, typically as a bearer token in the Authorization header, so a caller holding a token that was valid moments earlier could keep using it after it expired, for as long as the cached entry lived. The window is bounded by introspectionCacheTtl, which is 60 seconds by default and 300 to 600 seconds where the documentation's recommendation for internal services was followed, and it opens only for a token that the same Camel process introspected and cached while the token was still active. The issue grants nothing beyond what the token already carried: it allows no token forgery and no privilege escalation, and token introspection is not enabled by default, which is why the severity is assessed medium. The local JWT verification path, used when introspection is disabled, is not affected by this issue. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.16.x, 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, set introspectionCacheEnabled=false on the KeycloakSecurityPolicy, so that every request is checked against the introspection endpoint, which reports an expired token as inactive, at the cost of one introspection call per request. Lowering introspectionCacheTtl only narrows the window and does not close it. |
| CVE-2026-96616 | High | 2026-10-22 | Not applicable | No public exploit | Authentication tokens issued by the E3's web management interface on login are given an expiration time far beyond any reasonable session lifetime, effectively making them non-expiring. A token obtained through interception or device compromise remains valid for authenticated access for an extended period. |
| CVE-2026-54238 | Low | 2026-10-22 | Not applicable | No public exploit | Supabase Realtime provides Broadcast, Presence, and Postgres Changes via WebSockets. Prior to version 2.103.1, the REST broadcast endpoints accept an expired JWT when the exp claim is encoded as a JSON string instead of a JSON number. The same route rejects an expired integer exp token signed with the same tenant secret. The accepted request returns 202 and emits the broadcast to subscribers. This could allow an unauthenticated attacker can broadcast realtime messages to subscribers. The attack can be performed via the Internet/only from within the supabase project. The impact of broadcasting messages to subscribers is application specific. This issue has been patched in version 2.103.1. |
| CVE-2026-115362 | Low | 2026-10-22 | Not applicable | No public exploit | OpenBao before 2.6.4 and 2.7.x before 2.7.1 does not check Secret ID expiration at use in the AppRole auth method, leaving expired Secret IDs valid until the periodic tidy removes them. An attacker holding an expired, untidied Secret ID can log in and gain access beyond its TTL. |
| CVE-2026-115356 | Medium | 2026-10-22 | Not applicable | No public exploit | OpenBao before 2.6.4 and 2.7.x before 2.7.1 does not verify, when renewing a token issued by the Kubernetes Auth method, that the service account token originally used to authenticate is still valid. An authenticated attacker can keep renewing such tokens to persist access after the Kubernetes service account has been deleted. |
| CVE-2026-89035 | Critical | 2026-10-21 | Not applicable | No public exploit | MikroTik RouterOS through 7.24.5 contains a session token replay vulnerability in the WebFig interface that allows attackers to bypass authentication by replaying captured session tokens across new ECDH sessions. The makeSessionKey function in libucrypto.so generates tokens using fixed salts without incorporating channel-specific or session-specific input, and the user service validates tokens against the login store without verifying channel context, enabling stolen tokens to grant persistent administrative access until the token store is explicitly cleared. This vulnerability extends the impact of CVE-2025-61481, which identified the underlying transport-layer exposure without a corresponding fix. |
| CVE-2026-114137 | High | 2026-10-21 | Not applicable | No public exploit | Django REST framework is a toolkit for building Web APIs. From 3.12.0 until 3.18.2, TokenProxy.delete() in rest_framework/authtoken/models.py uses the proxy's user-id pk while the concrete Token token-string primary key identifies rows, so Django issues a deletion query that matches no row and reports zero deletions without raising an error. Applications, administrative integrations, or operational scripts that revoke credentials through a TokenProxy instance can therefore believe revocation succeeded while the token remains live and continues authenticating. DRF's own TokenAdmin.delete_model workaround is not affected, but other callers can leave access available indefinitely because DRF tokens do not expire automatically. This issue is fixed in version 3.18.2. |
| CVE-2025-0326 | High | 2026-10-21 | No exploit published | No public exploit | The system fails to invalidate existing access tokens associated with sub-organization users during sensitive account management operations such as password reset, role change, or sub-organization disablement. This oversight allows previously issued tokens to remain active even after the user's access context has been modified or revoked through administrative actions. The identified issue could lead to unauthorized access by a malicious actor, but only when all of the following conditions are met: previously issued access tokens remain active, and these tokens have been exposed to malicious actors. |
| CVE-2026-79624 | Critical | 2026-10-19 | Not applicable | No public exploit | Insufficient session expiration vulnerability in Apache Answer. This issue affects Apache Answer: through 2.0.2. Insufficient session invalidation allowed revoked users to continue accessing known private uploaded files with a stale visit token. Users are recommended to upgrade to version 2.0.3, which fixes the issue. |
| CVE-2026-12254 | Medium | 2026-10-19 | Not applicable | No public exploit | Netskope is notified about a potential gap in its agent (NSClient) where a system with Netskope Client while connecting to an access point with Captive Portal switches to a Network which already has internet connectivity, the Captive Portal does not close. This allows the possibility of abuse via the Captive Portal using a rogue access point to either access malicious sites or exfiltrate data.The issue impacts all versions prior to R142 |
| CVE-2026-110008 | Medium | 2026-10-19 | Not applicable | No public exploit | @fastify/oauth2 is a Fastify wrapper for OAuth2 login flows. In versions 7.2.0 through 8.3.1, the state and code-verifier cookies are set without a Path attribute at a login route with two or more path segments, while the clearing step at the OAuth callback writes them with a root path, so the original cookies survive the callback and the documented single-use guarantee for the state value does not hold. A state value an attacker learns stays valid for the rest of the browser session, letting the attacker drive their own authorization flow in the victim's browser and sign the victim in to the attacker's account (login CSRF). The issue is fixed in @fastify/oauth2 8.3.2, and users should upgrade to 8.3.2 or later. As a workaround, set an explicit cookie path so the set and the clear name the same cookie. |
| CVE-2025-36252 | Medium | 2026-10-19 | Not applicable | No public exploit | IBM Storage TS4500 Library 1.1.1.6 through 1.12.0.3 IBM TS4500 Tape Library/Diamondback Tape Library does not invalidate session which could allow an authenticated user to impersonate another user on the system. |
| CVE-2025-36069 | Medium | 2026-10-19 | Not applicable | No public exploit | 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-13173 | Medium | 2026-10-19 | No exploit published | No public exploit | Tokens associated with user sessions are not revoked when the corresponding user session is terminated, unless another SSO request is initiated. This occurs when the session-bound token feature is enabled with token binding validation and the "Revoke token upon user logout" option is not active. The software fails to automatically invalidate session-bound tokens upon user session termination. This vulnerability exists when token binding validation is enabled. As a result, a malicious actor possessing a valid session-bound token could exploit this condition to maintain unauthorized access to applications and resources even after the associated user session has ended, potentially leading to the exposure of sensitive user data. |
| CVE-2026-110024 | Medium | 2026-10-18 | Not applicable | No public exploit | @fastify/jwt is a JWT utility plugin for Fastify. In versions prior to 10.2.5, the top-level sign and verify methods replace the globally configured defaults with the per-call options instead of merging them, so passing any per-call option silently drops every global default that the call does not restate, including temporal protections such as token expiration and maximum accepted token age. A token signed this way carries no expiration claim and never expires, and verification stops enforcing a configured maximum age, so stale or never-expiring tokens are accepted. The route-level decorators for signing and verifying already merge options and are not affected. The issue is fixed in @fastify/jwt 10.2.5, and users should upgrade to 10.2.5 or later. |
| CVE-2025-71435 | Low | 2026-10-17 | Not applicable | No public exploit | Coder before 2.23.0 contains a session expiration bypass vulnerability that allows authenticated users to retain access after OIDC token expiry when no refresh token is issued. Users can keep their APIKey cookie active through regular use, extending it every 24 hours to access Coder indefinitely after losing OIDC authorization. |
| CVE-2026-96806 | Medium | 2026-10-15 | Not applicable | No public exploit | The Apache Airflow Keycloak auth manager did not end the session on logout: the logout route revoked the presented token, but `KeycloakJWTMiddleware` then issued a new, unrevoked token on the same response, so the user stayed logged in. Deployments using the Keycloak auth manager are affected: after a user logs out, anyone with later access to the same browser (for example on a shared workstation) can continue to act as that user. Users of apache-airflow-providers-keycloak are recommended to upgrade to apache-airflow-providers-keycloak 0.11.1 or later. |
| CVE-2026-89073 | Critical | 2026-10-14 | Not applicable | No public exploit | Insufficient Session Expiration vulnerability in Progress MOVEit Transfer. This issue affects MOVEit Transfer: before 2025.1.6 and from 2026.0.0 before 2026.0.4. |
| CVE-2026-107371 | Medium | 2026-10-13 | Not applicable | No public exploit | When the authorize() method is called with a maxAge parameter, the auth0.js library does not validate the auth_time claim in the resulting ID token against the requested maxAge value. As a result, an application may process an ID token that represents an authentication event older than the requested maximum age. |
| CVE-2026-78357 | Critical | 2026-10-12 | Not applicable | No public exploit | Previously issued authentication tokens are not immediately invalidated when an OTRS agent or customer user account is deactivated or its password is changed. As a result, an existing JWT may remain valid until its regular expiration time, which can be approximately 16 hours. An attacker who has previously obtained a valid authentication token can therefore continue to access OTRS with the privileges of the affected agent or customer user even after the corresponding account has been deactivated or the user's password has been changed. The vulnerability does not allow an attacker to obtain authentication tokens by itself. Exploitation requires possession of a previously issued and still valid token. The actual impact depends on the privileges associated with the compromised token. Customer user tokens are limited to the permissions of the affected customer account, while agent tokens may provide access to broader ticket, customer, or administrative functionality depending on the assigned permissions. This issue affects OTRS: * 7.0.X * 8.0.X * 2023.X * 2024.X * 2025.X * 2026.X before 2026.7.X |
| CVE-2026-109320 | Medium | 2026-10-12 | Not applicable | No public exploit | The Grav API plugin (grav-plugin-api) before 1.0.36 contains an improper session validation vulnerability that allows disabled accounts to keep API access, because SessionAuthenticator does not enforce account state. Disabled users can reuse an already authorized browser or remember-me session to call API endpoints until expiry, defeating operator revocation. |
| CVE-2026-109289 | Medium | 2026-10-12 | Not applicable | No public exploit | Open WebUI from 0.8.8 before 0.11.4 contains an improper authorization vulnerability that allows deactivated users to keep executing terminal commands through an already open terminal WebSocket. Because the terminal proxy route in terminals.py checks access only on the first message, deactivated users can keep running commands and reading or writing files on the terminal server. |
| CVE-2026-108809 | Low | 2026-10-12 | Not applicable | No public exploit | A vulnerability was identified in Eleveo Call Recording Software up to 10.3.0. This issue affects some unknown processing of the file /auth/realms/default/protocol/openid-connect/logout. The manipulation leads to session expiration. Remote exploitation of the attack is possible. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| CVE-2026-108803 | Medium | 2026-10-12 | Not applicable | No public exploit | A security vulnerability has been detected in y_project RuoYi up to 4.8.3. This impacts the function changeStatus of the file /system/config/add of the component Disable API. The manipulation leads to session expiration. It is possible to initiate the attack remotely. The vendor was contacted early about this disclosure but did not respond in any way. |
| CVE-2026-71575 | Critical | 2026-10-09 | No exploit published | No public exploit | The max_age authentication-freshness check in OidcClientCodeRequestFilter was inoperative due to a milliseconds/seconds unit mismatch and an inverted comparison polarity. Any relying party using setMaxAgeOffset to enforce re-authentication would silently accept sessions of any age, bypassing step-up authentication policies. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue. |
| CVE-2026-104084 | High | 2026-10-09 | Not applicable | No public exploit | SmarterMail before build 9777 contains a privilege escalation vulnerability where JWT access and refresh tokens embed a role claim at issuance that is not revalidated against the account's current role when redeemed through POST /api/v1/auth/refresh-token. Attackers who capture a refresh token issued before an administrator demotion, or a demoted user whose session was not actively polling at the time of demotion, can replay the stale token to obtain a new access token retaining the higher-privilege role (such as DomainAdmin or SysAdmin) until natural token expiry. |
| CVE-2026-107721 | Medium | 2026-10-08 | Not applicable | No public exploit | fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.0, fast-jwt createVerifier accepts Infinity for clockTolerance because its option validation checks type and negativity but not finiteness. In validateClaimDateValue, infinite positive and negative modifiers make exp and nbf comparisons always pass, allowing expired or not-yet-active tokens to be accepted. The verifier cache also derives infinite bounds, so entries created under this configuration can remain valid until eviction. Exploitation requires an application administrator or equivalent configuration path to set clockTolerance to Infinity. This issue is fixed in version 6.3.0. |
| CVE-2026-107275 | Medium | 2026-10-08 | Not applicable | No public exploit | @fastify/jwt is a JSON Web Token plugin for the Fastify web framework. In versions before 10.2.3, a time span passed to expiresIn, notBefore, or maxAge that the plugin's parser cannot read, such as a compound span, a month unit, an ISO 8601 duration, a decimal comma, or a value with surrounding whitespace, is silently dropped instead of refused. On the signing path this produces a token with no expiration claim that never expires, and on the verification path a configured maxAge stops being enforced, so a token that should be rejected for age is accepted. The issue is fixed in @fastify/jwt 10.2.3, and users should upgrade to 10.2.3 or later. As a workaround, pass these options as a number of seconds, or verify that any time-span string parses to a finite value before relying on it. |
| CVE-2024-8122 | Medium | 2026-10-08 | Not applicable | No public exploit | The WSO2 Identity Server fails to enforce a default expiry time for SMS One-Time Passwords (OTPs) used in multi-factor authentication (MFA). This allows unused OTPs to remain valid indefinitely, presenting an opportunity for malicious actors to conduct brute force attacks by repeatedly guessing the OTP. The absence of automatic expiration for OTPs grants attackers an unlimited timeframe to attempt guessing the correct code. A successful brute force attack can lead to an MFA bypass, resulting in the unauthorized takeover of a user's account and compromising the security and privacy of both the individual and the system. |
| CVE-2026-83540 | High | 2026-10-07 | Not applicable | No public exploit | When password or public key authentication is used with the Windows port of wolfSSHd, the Windows logon token acquired for one authenticated connection is not released before a token is acquired for a subsequent connection, resulting in user login poisoning between connections. A less privileged user with a valid account on the server can exploit this to force a login as a more privileged user. The vulnerability was introduced with the initial Windows port of wolfSSHd in wolfSSH version 1.4.15 and affects all versions through 1.5.0. Non-Windows builds of wolfSSHd are not affected. |
| CVE-2026-105690 | Medium | 2026-10-05 | Not applicable | No public exploit | Penpot is an open-source design and prototyping platform. Prior to 2.18.0, logout clears the browser's auth-token cookie without revoking the corresponding server-side session. A previously captured session token remains usable after the victim logs out and can continue to make authenticated requests with the victim's authority until natural expiration. This issue is fixed in version 2.18.0. |
| CVE-2026-97212 | Medium | 2026-10-02 | Not applicable | No public exploit | 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-2026-66253 | Low | 2026-10-01 | Not applicable | No public exploit | iControl is affected by a Session Timeout vulnerability, which could allow an attacker to exploit an unattended or abandoned active session, enabling unauthorized access to the application and the ability to perform actions on behalf of the victim. |
| CVE-2026-103283 | High | 2026-10-01 | Not applicable | No public exploit | Ghost versions 6.20.0 before 6.57.1 contain a session handling vulnerability that allows authenticated staff users to log in as any other staff user with only the password, bypassing two-factor authentication. Attackers with valid staff credentials can exploit improper session management to impersonate other staff members and gain unauthorized access to administrative functions. |
| CVE-2026-103279 | High | 2026-10-01 | Not applicable | No public exploit | Ghost versions from 3.10.0 before 6.34.0 fail to fully invalidate all sessions after a password change. Attackers with a stolen session cookie can maintain access to user accounts even after the associated user changes their password. |
| CVE-2026-101271 | Low | 2026-09-29 | Not applicable | No public exploit | OAuth credentials (access tokens) are valid for the entirety of their lifetime, even if the application (OAuth client) they are bound to is manually disabled. |
| CVE-2026-88805 | High | 2026-09-28 | Not applicable | No public exploit | Incorrect credential cleaning on logout could be used by remote attackers to keep access credentials even after the account was logged out. Affected is SUSE Rancher 2.15 before 2.15.2. |
| CVE-2026-100554 | Low | 2026-09-26 | Not applicable | No public exploit | OpenClaw (npm package 'openclaw') versions >= 2026.5.12 and < 2026.8.1 do not immediately invalidate Canvas HTTP authorization when a paired node is revoked. Node revocation invalidates the WebSocket client, but Canvas HTTP authorization continues to accept and renew the previously granted capability until WebSocket close cleanup completes. As a result, a revoked paired node can continue exercising its Canvas capability against the capability's configured routes during the close grace period. The issue is fixed in 2026.8.1; as a workaround, restart the Gateway after revoking a node that has Canvas access. |
| CVE-2026-82566 | High | 2026-09-24 | Not applicable | No public exploit | The Botslab G980H dash camera firmware contains a session management vulnerability in which authentication state can remain valid after the associated client connection has been terminated or replaced. Under certain connection conditions, a newly established connection can displace an existing client while previously established session state remains active until a separate expiration mechanism invalidates it. An unauthenticated attacker with adjacent network access could potentially take advantage of this residual authentication state to access functionality associated with another client's session. |
| CVE-2026-75907 | High | 2026-09-24 | Not applicable | No public exploit | The door access control on a Norwegian Cruise Line asset grants entry based only on the credential's static 7-byte UID stored on an NTAG212 NFC chip. A UID is a manufacturer serial number sent in the clear on every read and is not intended to be secret or to authenticate the holder. Validating on the UID of the NTAG212 NFC chip alone is identification, not authentication, and the credential has no challenge-response capability that would resist copying. |
| CVE-2026-92378 | Medium | 2026-09-23 | Not applicable | No public exploit | A session management vulnerability exists in the Legacy UI Reduced Function Login feature of NT-ware uniFLOW Online. Under specific timing conditions during Service Offline Emergency Mode, a previously authenticated session may be retained after logout, which could allow a subsequent user to be authenticated as the previous user and gain unauthorised limited access to device functionality. |
| CVE-2026-73586 | Medium | 2026-09-23 | Not applicable | No public exploit | Dell Secure Connect Gateway (SCG) Policy Manager, versions prior to 5.34.00.16, contains an Insufficient Session Expiration vulnerability. A low privileged attacker with adjacent network access could potentially exploit this vulnerability, leading to Elevation of privileges, Protection mechanism bypass, and Unauthorized access. |
| CVE-2026-79313 | Critical | 2026-09-22 | Not applicable | No public exploit | webpy web.py 0.76 is vulnerable to Insufficient Session Expiration. The application's session management relies on periodic cleanup to expire sessions instead of checking the last-access time when a session is loaded. As a result, an expired session whose record has not yet been cleaned up can still be replayed and used, allowing an attacker holding a previously valid session cookie to continue accessing protected resources after the configured idle timeout. |
| CVE-2026-86473 | Critical | 2026-09-21 | Not applicable | No public exploit | Apache Airflow: the Core API logout endpoint revokes only a session token presented as the _token cookie. When a client logs out presenting its credential as an Authorization bearer header instead, the endpoint returns its normal logout response but revokes nothing, so the token remains valid until it expires. An attacker who already holds a copy of that token keeps the victim's access after the victim has logged out and believes the session ended; the default token lifetime is 24 hours and is configurable. Affects API clients that authenticate with a bearer token rather than the browser session cookie. The attacker must already possess a copy of a valid token; obtaining one is outside the scope of this issue, and no privileges beyond the victim's own are gained. Users of apache-airflow are recommended to upgrade to apache-airflow version 3.3.2 or later, which fixes the issue. |
| CVE-2026-79317 | Medium | 2026-09-21 | Not applicable | No public exploit | A session invalidation flaw exists in x-ui 0.3.2. The full user object is stored in a client-side signed cookie, and authentication only checks that a user object can be retrieved from the cookie without re-validating against the database or any session version. When an administrator changes the username or password, previously issued session cookies are not revoked, so an attacker who holds a pre-change admin cookie can continue accessing and operating the management interface after the credentials have been rotated. |
| CVE-2026-92976 | Medium | 2026-09-18 | Not applicable | No public exploit | A stored Cross-Site Scripting (XSS) vulnerability in the profile management functionality of T-Systems’ TAO 2.0 suite. An authenticated user could inject malicious HTML or JavaScript content into the fields containing their personal data. The content entered is stored and displayed without being properly sanitised when another user, including administrative staff, views the affected profile. Successful exploitation could allow JavaScript code to be executed in the victim’s browser, access to information available within the session, or the performance of actions using the victim’s permissions. |
| CVE-2026-86533 | Critical | 2026-09-17 | Not applicable | No public exploit | Insufficient Session Expiration vulnerability in team-alembic AshAuthentication and AshAuthentication Phoenix allows a revoked session to remain fully authenticated. A resource configured with session_identifier :jti and require_token_presence_for_authentication? disabled stores its session value as <jti>:<subject>. The jti is there so that signing out can revoke that one session. Neither reader consults it: AshAuthentication.Plug.Helpers.authenticate_resource_from_session/4 and AshAuthentication.Phoenix.LiveSession.on_mount/4 both split the value with split_identifier/2, discard the jti and pass the bare subject to AshAuthentication.subject_to_user/3, which reloads the record. The token-presence branch of each function does check its token, calling AshAuthentication.TokenResource.Actions.get_token/3 with the jti and the purpose user. Because the revocation record is never read, neither its revoked state nor its expiry constrains the session, so a session captured before sign-out keeps working. This issue affects ash_authentication: from 4.9.1 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14; ash_authentication_phoenix: from 2.10.0 before 2.17.4 and from 3.0.0-rc.0 before 3.0.0-rc.11. |
| CVE-2026-81637 | Low | 2026-09-17 | Not applicable | No public exploit | Insufficient Session Expiration vulnerability in team-alembic AshAuthentication allows an attacker who obtains a victim's OAuth2 state value to replay the callback and sign that victim into an attacker-controlled account. AshAuthentication.Strategy.OAuth2.Plug.callback/2 clears the stored session_params through a rebinding step inside its with chain, conn <- delete_session(conn, session_key). Elixir evaluates the else block in the scope enclosing the with, so every failure path (the provider returning ?error=access_denied, an invalid code, a token-exchange error, or a registration or sign-in failure) reaches store_authentication_result/2 holding the original connection and the session entry is never removed. The value the module's own comment describes as protection against a CSRF-related attack is therefore consumed only when authentication succeeds, and survives a cancelled or failed attempt until the next request phase or session expiry. This issue affects ash_authentication: from 0.6.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14. |
| CVE-2026-92616 | High | 2026-09-16 | Not applicable | No public exploit | FileRise before version 3.28.0 contains a privilege escalation vulnerability that allows authenticated low-privilege attackers to gain unauthorized read and write access by exploiting improper session isolation between the WebDAV interface and the web application session context. Attackers can combine valid Basic-Auth credentials with an active admin PHPSESSID cookie to bypass authorization boundaries, as the WebDAV layer incorrectly inherits elevated privileges from an ambient web session rather than enforcing independent stateless authentication per RFC 4918. |
| CVE-2026-92358 | Medium | 2026-09-16 | No exploit published | No public exploit | A flaw was found in the first broker login flow of Keycloak. When a user confirms an account-linking request from a different browser, a temporary proof is created to validate the link. However, this proof is not properly cleared after the link is established or when the user later manually removes the link. An attacker who controls the external identity can exploit this leftover proof to silently re-establish the link and gain unauthorized access to the victims account without any further confirmation. |
| CVE-2026-86462 | Critical | 2026-09-16 | Not applicable | No public exploit | Apache Airflow FAB provider: changing a user's password through the Admin user-edit PATCH endpoint does not invalidate that user's existing database-backed sessions. An attacker who already holds a copy of the victim's session cookie keeps full access as that user after the password change, so the password reset does not evict them. Affects deployments using the FAB auth manager with database-backed sessions; an administrator (or the user themselves) performing a routine password change is the trigger, and no attacker interaction with the endpoint is needed. This is a second, independent route to the outcome addressed by CVE-2026-82311, which corrected an identifier comparison in the session-invalidation helper. That fix does not repair this endpoint, because the PATCH path never calls the helper at all. Deployments that applied the CVE-2026-82311 fix must also upgrade for this one. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which fixes the issue. |
| CVE-2026-85387 | Low | 2026-09-16 | Not applicable | No public exploit | Concrete CMS before 9.5.4 re-authorized OAuth REST API requests from the bearer token alone and did not re-check the state of the account the token had been issued to. The resource server's authorization validator confirmed only that a token existed, had not expired, and had not been explicitly revoked, and deactivating a user did not revoke that user's outstanding tokens. As a result, a deactivated user retained full access to /ccm/api/1.0/* for the remaining lifetime of any token already issued to them. The same gap applied to accounts that had been deleted or locked pending a forced password reset. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.0 with vector CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Myq Larson for reporting. |
| CVE-2026-82311 | Critical | 2026-09-16 | Not applicable | No public exploit | Apache Airflow FAB provider: resetting a user's password does not delete that user's existing database-backed sessions, despite documented behaviour that it does. The cleanup compares the string identifier Flask-Login stores in the session against the user's integer database identifier, so the comparison never matches and no session is removed. An attacker who already holds a copy of the victim's session cookie keeps access as that user after the password change, so the reset does not evict them. Affects deployments using the FAB auth manager with `[fab] session_backend=database`. The trigger is an administrator (or the user) running the supported password-reset command as a containment action after a session cookie has been compromised; the secure-cookie backend is out of scope, as it documents that it cannot centrally delete sessions. apache-airflow-providers-fab 3.9.0 also fixes CVE-2026-86462, a second, independent route to the same outcome via the Admin user-edit endpoint; a single upgrade closes both. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which compares the identifiers consistently. |
| CVE-2026-82310 | High | 2026-09-16 | Not applicable | No public exploit | Apache Airflow FAB provider: deactivating a user account does not stop tokens issued to that account before deactivation. Password authentication correctly rejects the disabled account, but the Core API continues to accept an existing, unexpired token naming it, and lets that token mint a replacement — so the account keeps its role-scoped access indefinitely after an administrator has disabled it. The user replays their own legitimate credential; no signature forgery or privilege escalation is involved, and the access stays within the roles the account already held. Affects deployments using Airflow 3 with the FAB auth manager and Core API token authentication, where an administrator deactivates an account whose row remains in the database and whose previously issued token has not expired. The trigger is administrative deactivation as a containment action, which silently fails to contain. Users of apache-airflow-providers-fab are recommended to upgrade to version 3.9.0 or later, which rejects tokens naming a deactivated account. |
| CVE-2026-88262 | High | 2026-09-15 | Not applicable | No public exploit | Insufficient session expiration vulnerability in bizwell xClick allows Authentication Bypass. This issue affects xClick: R2, R3, and R3.1. |
| CVE-2026-55617 | Medium | 2026-09-15 | Not applicable | No public exploit | Hydro is a next-generation high-performance online judge platform. From 4.10.4 until 5.0.2, the session recreation logic in packages/hydrooj/src/service/layers/base.ts creates a replacement session token without deleting the previous token from the server-side session token store, so an old sid cookie can remain valid after logout or another renewal flow. An attacker who possesses a victim's previously valid stale cookie can replay it over HTTP or HTTPS without knowing the victim's username or password and without victim interaction at exploitation time. Successful replay can take over the victim's account, disclose private data, and permit unauthorized modification or deletion of data available to that account. This issue is fixed in version 5.0.2. |
| CVE-2026-81268 | High | 2026-09-10 | Not applicable | No public exploit | IBM Langflow OSS 1.0.0 through 1.11.5 could allow a remote authenticated attacker to execute flows and obtain sensitive information due to insufficient session expiration of API keys after user deactivation. |
| CVE-2026-80174 | Medium | 2026-09-09 | Not applicable | No public exploit | Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Insufficient Session Expiration vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to session theft. |
| CVE-2026-55250 | High | 2026-09-08 | Not applicable | No public exploit | Maravel, a PHP framework oriented towards dependency injection, prior to version 10.74.0 has a high-severity Token Replay Vulnerability arising from a structural lifecycle mismatch between stateless token validation engines and high-performance relational caching layers. Any application with low cache memory that causes premature eviction to free up memory and applications running macropay-solutions/maravel-framework that utilize tymon/jwt-auth for API token authentication and blacklist management or any other package that does the same may be affected. This architectural risk might also impact native Laravel applications utilizing cache tags under specific volatile or eviction-capped environments. tymon/jwt-auth automatically probes for cache tag support. If found, it forcefully wraps 14-day token blacklist entries (jti) inside a relational tymon.jwt tag. In environments where the O(1) Atomic Lazy Eviction model is active — either natively inside Maravel-Framework v20.x or manually backported into v10.x via the explicit DI container singletons provided in PR #104 (App\Cache\TaggedCache and App\Cache\TagSet) — a strict global tracking ceiling (Container::TAGGED_CACHE_TTL_CAP_SECONDS) of 7,200 seconds (2 hours) is enforced to secure the system against memory index bloat. This ceiling forcefully truncates the 14-day blacklist lifespan down to a maximum of 2 hours, after which individual tracking keys naturally expire and disappear from the active cache window. Furthermore, because the optimized engine implements a generational version matrix to achieve O(1) flush speeds, any programmatic or manual invocation of a tag flush or reset (e.g., Cache::tags([...])->flush()) instantly bumps the internal atomic master version pointer. This shifts the computed cryptographic composite hash (sha1($this->tags->getNamespace())) for all overlapping components, rendering the entire existing index immediately unreachable. Consequently, through either natural 2-hour expiration or an intervening tag flush execution (like the cache naturally cleaning old values to free up memory), the invalidation state records are entirely wiped out. Because the tokens' physical cryptographic signatures remain structurally valid for up to 14 days, stolen, hijacked, or legitimately logged-out tokens are instantly and silently resurrected across the entire API gateway, leaving the application critically vulnerable to widespread Token Replay Attacks. Because this issue is caused by an upstream architectural assumption within the tymon/jwt-auth package rather than a core defect inside the framework, there is no direct framework version upgrade that can safely bypass this lifecycle collision without breaking business cache recycling bounds. Maravel version 10.74.0 introduced a way to backport the new fixed tagged cache from 20.x into 10.x by resolving TagSet and TaggedCache from DI, which is how this latent architectural lifecycle vulnerability was discovered. Users must apply the decoupled configuration workaround outlined below. As a workaround, make sure that cache memory size does not generate early natural evictions from cache to free up space, deleting blacklisted jwt ids before they expire. Applications must decouple flat authentication vectors from the relational tagging subsystem. This forces token identifiers to write directly to the primary cache keyspace as flat, un-tagged key-value pairs where they securely retain their unclipped 14-day lifecycle. |
| CVE-2026-61608 | Medium | 2026-09-04 | Not applicable | No public exploit | SolidInvoice is an open-source invoicing platform. Prior to version 3.0.1, `UserInvitation` entities have no expiry timestamp. Invitation links mailed to users remain valid indefinitely, meaning a leaked, forwarded, or archived invitation email can be used at any time in the future to join a company or silently add a compromised email account to a company. Version 3.0.1 fixes the issue. |
| CVE-2026-84480 | Critical | 2026-09-01 | Not applicable | No public exploit | WWBN AVideo fails to validate password recovery token expiration in userRecoverPassSave.json.php, allowing attackers to use expired tokens to reset account passwords indefinitely. Attackers who obtain a recovery token can use it at any time to change the target account's password and gain full account access. |
| CVE-2026-84203 | High | 2026-09-01 | Not applicable | No public exploit | Memos versions 0.26.0 through 0.30.0 fail to revoke refresh tokens when a user changes their password, allowing attackers to maintain account access. An attacker with a stolen refresh token can call the RefreshToken RPC to obtain new access tokens and rotate the refresh token indefinitely, bypassing the password change security measure. |
| CVE-2026-82469 | Medium | 2026-08-29 | Not applicable | No public exploit | Rodauth before 2.47.0 contains an authentication bypass vulnerability in the jwt_refresh route that issues new JWT access tokens without requiring a refresh token. Attackers can present an access token to the refresh route via non-POST methods to obtain a new valid access token, enabling indefinite account access with temporary token possession. |
| CVE-2026-81826 | Critical | 2026-08-27 | Not applicable | No public exploit | Affected versions of Flowintel do not revoke existing authenticated sessions when a user’s password is changed. This means that if an attacker already possesses a valid session—for example, from prior access or a stolen session token—the victim changing their password does not terminate that attacker’s access. The session remains usable until it expires naturally. The upstream commit describes this directly as: “session keeps working until it expires.” The fix detects password changes and explicitly invokes _invalidate_user_sessions(user.id) after the database update. This is applied in both edit_user_core() and admin_edit_user_core(). Version impacted >=3.3.0 |
| CVE-2025-62342 | Medium | 2026-08-27 | Not applicable | No public exploit | HCL IntelliOps Event Management (IEM) is affected by a Session Deletion Vulnerability. It may allow improper handling of user sessions, resulting in sessions not being fully terminated after logout or deletion. |
| CVE-2026-77130 | Medium | 2026-08-25 | Not applicable | No public exploit | The extension fails to properly validate the expiration of a client-supplied JWT token, allowing an attacker in control of a valid API key to authenticate with an expired token. Exploitation requires the attacker to already be in control of the SYSSY project's API key. |
| CVE-2026-73180 | Medium | 2026-08-25 | No exploit published | No public exploit | Insufficient Session Expiration vulnerability in Apache Tomcat meant that if the session ID for an authenticated HTTP session was changed after a WebSocket connection had been established under that authenticated HTTP session, the WebSokcet session would not be closed as required by the Jakarta WebSocket specification when the HTTP session ended. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.24, from 10.1.0-M1 through 10.1.57, from 9.0.0.M1 through 9.0.120. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100, from 7.0.43 through 7.0.109. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.25, 10.1.58 or 9.0.121, which fix the issue. |