Overview 725 matches · 42 in Waratek scope · 0 protected · 4 exploited · 0 CISA KEV · 5 public PoC · 0 EPSS ≥ 0.5
725matches
42in Waratek scope5.8%
0protected0.0%
4exploited0.6%
0CISA KEV0.0%
5public PoC0.7%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
42
5.8%
Outside Waratek scope
4
0.6%
Not applicable
679
93.7%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
725
100.0%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 285 / year
20131
Not applicable1
High1
not blocked1
No public exploit1
20141
Not applicable1
Medium1
not blocked1
No public exploit1
20150
20160
201713
No exploit published2
Not applicable11
Critical2
High5
Medium6
not blocked13
Working exploit published1
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
202050
No exploit published2
Outside Waratek scope1
Not applicable47
Critical7
High21
Medium19
Low3
not blocked50
Working exploit published2
No public exploit48
202155
No exploit published3
Outside Waratek scope1
Not applicable51
Critical15
High20
Medium18
Low2
not blocked55
Proof of concept only4
No public exploit51
202252
No exploit published1
Outside Waratek scope1
Not applicable50
Critical13
High18
Medium18
Low3
not blocked52
Proof of concept only6
No public exploit46
202365
No exploit published6
Outside Waratek scope1
Not applicable58
Critical14
High27
Medium20
Low4
not blocked65
Exploited1
Proof of concept only21
No public exploit43
202474
No exploit published3
Not applicable71
Critical11
High32
Medium29
Low2
not blocked74
Working exploit published1
Proof of concept only9
No public exploit64
202591
No exploit published3
Not applicable88
Critical7
High36
Medium38
Low10
not blocked91
Exploited3
Working exploit published1
Proof of concept only14
No public exploit73
2026285
No exploit published20
Not applicable265
Critical31
High77
Medium134
Low42
Unknown1
not blocked285
Proof of concept only73
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-126658 | Medium | 2026-11-11 | Not applicable | Proof of concept only | ByteStash 1.5.10 before 1.6.2 contains an insufficient session expiration vulnerability that allows holders of API keys to keep access after account deactivation because validateApiKey never checks account status. Attackers holding a deactivated account's API key can read, create, modify and delete its snippets via /api/snippets and use every MCP tool via /mcp. |
| 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-123528 | High | 2026-11-08 | Not applicable | Proof of concept only | Vikunja before 2.7.1 contains an insufficient session expiration vulnerability that allows holders of revoked access tokens to keep authenticating because SetupTokenMiddleware skips session and account-status checks. Attackers with a stolen token can, after logout, password reset, or account disabling, mint OAuth sessions via /oauth/authorize or tk_ API tokens for persistent access. |
| 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-84155 | Medium | 2026-11-06 | Not applicable | Proof of concept only | CodeChecker's web server fails to fully invalidate a session token on logout when the server runs with more than one API worker process (the default). Each worker process maintains its own in-memory session cache; logout only clears the cache of the single worker that handles the request (plus the shared database record). Other workers continue to honor the destroyed token from their stale in-memory copies until the session's lifetime expires. An attacker who has captured a valid token can therefore keep impersonating the user after the user has logged out. |
| 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-54375 | High | 2026-11-04 | Not applicable | Proof of concept only | VitaFit Android application (com.vt.vitafit) before 2.8.1.0 contains an insecure session management vulnerability that allows attackers to extract or intercept unencrypted m_session_id tokens stored in application backups, which remain valid for ten years. Attackers can use a stolen session token to read and modify the victim's account or delete the account's authentication record, preventing the legitimate owner from logging in again. |
| 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-118665 | High | 2026-10-28 | Not applicable | Proof of concept only | GraphQL Tools provides utilities for building, stitching, and mocking GraphQL schemas. Prior to version 1.1.36 of the GraphQL Tools legacy WebSocket executor package, buildWSLegacyExecutor in packages/executors/legacy-ws/src/index.ts retains request.extensions.connectionParams in the closure-scoped executorConnectionParams object after cleanupWebsocket closes a connection. When one executor is reused across different authorization contexts, a later request that omits a sensitive key can send an earlier caller's Authorization or tenant value in its connection_init payload, causing the downstream server to authenticate the later caller as the earlier user. Applications that create a new executor for every request are not affected. This issue is fixed in version 1.1.36 of the GraphQL Tools legacy WebSocket executor package. |
| 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-2026-111919 | High | 2026-10-17 | Not applicable | Proof of concept only | Vikunja 0.22.0 before 2.7.0 contains an improper access revocation vulnerability that allows removed collaborators to keep receiving project data through webhooks they created. Former collaborators keep receiving task titles and descriptions through their webhook, including content created after their access was revoked. |
| CVE-2026-111917 | High | 2026-10-17 | Not applicable | Proof of concept only | Vikunja 2.3.0 before 2.7.0 contains an improper session validation vulnerability that allows attackers to keep WebSocket access after revocation because handleAuth never checks the JWT sid claim against the sessions table. Attackers holding a stolen access token can open or maintain connections to /api/v2/ws after session deletion or TOTP enrollment, continuing to receive the victim's notification.created pushes, including comment, task and project content. |
| 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-57493 | Medium | 2026-10-14 | Not applicable | Proof of concept only | FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 3.16.0, FileRise stores the isAdmin flag in remember-me tokens and restores that stale value during automatic login instead of resolving the account's current role from users.txt. A user who was issued a token while an administrator can retain administrator access after demotion, and token rotation copies the stale privilege into each replacement token. Exploitation requires possession of the pre-demotion remember-me token. This issue is fixed in version 3.16.0. |
| CVE-2026-74037 | High | 2026-10-13 | Not applicable | Proof of concept only | Wazuh 4.0.0 before 4.14.8 fails to invalidate issued tokens for run_as users with zero static roles, because check_token never consults the blacklist. Attackers with revoked administrator grants can continue authenticating and self-link the administrator role to permanently retain privileged access. |
| 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-84321 | Medium | 2026-10-12 | Not applicable | Proof of concept only | Nginx UI is a web user interface for the Nginx web server. Prior to 2.4.1, GenerateShortToken creates standalone short-token records without a long Token value, but DeleteUserTokens invalidates cached entries only when the long Token field is nonempty. A revoked short token can therefore remain in the short_token cache and authenticate again if the associated account is re-enabled before the cache entry expires because GetTokenUserByShortToken reads the surviving entry, restoring access to HTTP or WebSocket routes that accept short-token authentication. This issue is fixed in version 2.4.1. |
| 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-109362 | Medium | 2026-10-12 | Not applicable | Proof of concept only | Heym v0.0.5 before v0.0.113 contains a broken access control vulnerability that allows former collaborators to keep executing JWT-auth workflows by reusing scoped workflow:execute tokens after share removal. Attackers can mint a token with a TTL up to 10 years, which the owner cannot list or revoke, and repeatedly run the workflow consuming shared credentials. |
| 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-108785 | Low | 2026-10-12 | Not applicable | Proof of concept only | A flaw has been found in macrozheng mall up to 1.0.3. This issue affects the function JwtTokenUtil.refreshHeadToken of the file /admin/refreshToken of the component JwtAuthenticationTokenFilter. This manipulation of the argument token causes session expiration. The attack may be initiated remotely. The exploit has been published and may be used. Patch name: 9bfc2fd2c4aaa4ac519e9152e65d673a5380de1a. To fix this issue, it is recommended to deploy a patch. |
| 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-107719 | Medium | 2026-10-08 | Not applicable | Proof of concept only | fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.4, the fast-jwt createVerifier cache can continue accepting a previously valid, signed JWT after its exp time when caching is enabled and the token has exp but no iat. In src/verifier.js, cacheSet derives the exp cache deadline only when iat is present, so the cache falls back to cacheTTL, and a later cache hit returns the saved payload before verifyToken rechecks expiration. An attacker who can replay the same cached bearer token can extend access until the cache entry expires, but cannot forge a token through this issue. This issue is fixed in version 6.3.4. |
| 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-46437 | Medium | 2026-10-07 | Not applicable | Proof of concept only | wger is a free, open-source workout and fitness manager. Versions prior to 2.6 have a vulnerability in the authentication/session lifecycle of `wger` where bearer-style API credentials remain valid after a user logs out and after a user changes their password. An attacker who steals a victim’s DRF authtoken (`Authorization: Token ...`) or JWT refresh token can continue to access protected `/api/v2/*` endpoints until the token is manually rotated/deleted (DRF token) or naturally expires (JWT refresh). Version 2.6 contains a patch. |
| 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-104468 | Medium | 2026-10-02 | Not applicable | Proof of concept only | YesWiki before 4.6.7 contains an insufficient session expiration vulnerability that allows attackers to reuse old password reset links because tokens lack expiry timestamps. Attackers who obtain an unused reset URL from mailboxes, logs, backups, or browser history can submit a new password through checkEmailKey() and take over accounts. |
| 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-102367 | Medium | 2026-09-29 | Not applicable | Proof of concept only | mall4j through 4.0 contains an insufficient session expiration vulnerability in the token refresh endpoint that fails to validate the enabled flag when issuing new sessions. Disabled user accounts can indefinitely renew their sessions through the POST /token/refresh endpoint, retaining access that account disabling was intended to remove. |
| 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-100711 | High | 2026-09-26 | Not applicable | Proof of concept only | froxlor versions before 2.3.12 fail to invalidate existing panel sessions, API keys, and 2FA trust cookies when a user password is changed. Attackers holding hijacked sessions, valid API keys, or 2FA trust tokens retain full account access after password rotation, bypassing incident response actions. |
| CVE-2026-100624 | Medium | 2026-09-26 | Not applicable | Proof of concept only | Capgo.app before 12.264.5 does not enforce upload expiry or build lifecycle state in the /build/upload/:jobId TUS proxy endpoint. When a native build request is created, an upload_expires_at timestamp (one hour) and a 'pending' status are stored in build_requests, but the upload proxy loads only app_id, owner_org, builder_job_id, and upload_path and checks only the app.build_native permission before forwarding POST, PATCH, and HEAD requests to the internal builder. As a result, an authenticated caller holding app.build_native permission for the app can continue writing to the build upload session after the stored expiry has passed or after the build has moved beyond the upload phase, unless the separate builder service independently rejects the request. The issue is fixed in 12.264.5. |
| 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-67242 | Medium | 2026-09-25 | Not applicable | Proof of concept only | RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.9 and 4.3.3, OAuth2 isinteger(Exp) guard skips token-expiry checks for float exp. validatetokenexpiry/1 (lines 208-214) and expirytimestamp/1 (138-144) both guard with 'when isinteger(Exp)' and fall through to ok/never for float values. josejwt:verify validates only the signature, not exp. With float exp, no expiry validation occurs anywhere in the If the IdP emits exp as a JSON float (RFC 7519 permits fractional NumericDate), both the login-time expiry check and the mid-connection disconnect timer are silently skipped , an already-expired token is accepted, and connections never time OAuth2 backend enabled IdP emits float exp (uncommon; mainstream IdPs emit integers) Attacker possesses a previously-valid signed. This issue is fixed in versions 4.2.9 and 4.3.3. |
| CVE-2026-100502 | Medium | 2026-09-25 | Not applicable | Proof of concept only | Flame through 2.4.0 contains an insufficient session expiration vulnerability in the login endpoint that allows attackers with former admin access to obtain tokens with arbitrary lifespans by supplying unvalidated duration parameters. Attackers can mint near-permanent administrator tokens that survive password changes, retaining full control of the dashboard since tokens are verified only against a static JWT secret that is never rotated. |
| CVE-2026-97056 | High | 2026-09-24 | Not applicable | Proof of concept only | SigNoz versions from v0.98.0 up to (but not including) v0.143.0, when configured to use the opaque session tokenizer (which was not the default before v0.143.0), do not revoke a user's existing login sessions when the user's password is reset with a reset token (UpdatePasswordByResetPasswordToken, reachable via POST /api/v2/factor_password/reset) or when the user is deleted (DeleteUser, reachable via DELETE /api/v2/users/{id}). Neither code path calls the tokenizer's DeleteTokensByUserID, so cached tokens and identities are left in place. An attacker who already holds a session token for the account — for example from a stolen browser session or from a user being offboarded — retains the account's full access, up to administrator, after a password reset until the token reaches its configured maximum lifetime (30 days by default), and after user deletion until the token next rotates (30 minutes by default). This defeats password reset and user deletion as a means of terminating access. The issue is fixed in v0.143.0. |
| CVE-2026-87720 | High | 2026-09-24 | Not applicable | Proof of concept only | Incorrect Authorization (CWE-863) in project name normalization (ProjectUtil.stripGitSuffix) and ProjectCache eviction logic (ProjectCacheImpl) in Gerrit Code Review versions 2.16.0 through 3.12.9, 3.13.0 through 3.13.8, and 3.14.0 through 3.14.2 allows an authenticated user (or an unauthenticated user if the repository was previously public) to cause unauthorized disclosure of private repository content and durable restoration of revoked project-owner administrative privileges via crafted requests using repeated .git suffixes (such as project.git.git) across REST APIs, Gitiles, or SSH Git commands. Because Gerrit strips only a single terminal .git suffix when constructing the logical ProjectCache key while JGit (FileKey.lenient) resolves the suffixed alias to the same canonical bare repository on disk, revoking read access or removing owner rules on the canonical project name fails to evict the cached alias ProjectState during the cache validity window, enabling reads of newly created private commits or writes to refs/meta/config. This issue is fixed in Gerrit Code Review versions 3.12.10, 3.13.9, and 3.14.3. |
| 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-86698 | Low | 2026-09-22 | Not applicable | Proof of concept only | Insufficient Session Expiration vulnerability in OAuth token issuance in hexpm hexpm allows a user whose organization membership or session has ended to keep reading the organization's private packages and their documentation tarballs via a retained refresh token. generate_refresh_token/4 in lib/hexpm/oauth/jwt.ex signs the refresh token with the same iss, aud and scope claims as the access token, so it carries the same repository:<org> scopes. The CDN service that serves private repositories verifies the signature and time claims and then authorizes from the scope claim, with no database lookup and no way to tell the two token kinds apart. Removing a member or revoking a session therefore takes effect at the CDN only when the 30 day refresh token expires, instead of after the 30 minute access token lifetime. Access is read-only and limited to organizations the account belonged to when the token was granted. This issue affects hex.pm: from 2025-10-10 before 2026-09-22. |
| 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. |