CVE-2026-126658
ByteStash 1.5.10 before 1.6.2 contains an insufficient session expiration vulnerability that allows holders of API keys to keep access after
CVSS
5.4
Média
EPSS
—
KEV
—
Exploit Today
—
0-100
Publicado: 11 de nov. de 2026 · Última mod.: 11 de nov. de 2026 · CWE-613
Ainda não há histórico EPSS suficiente.
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.
- github.comhttps://github.com/jordan-dalby/ByteStash/blob/v1.6.1/server/src/repositories/apiKeyRepository.js#L70-L78
- github.comhttps://github.com/jordan-dalby/ByteStash/commit/eb4ecdfc30f2e7d1424137fa7fe3a9eed663218b
- github.comhttps://github.com/jordan-dalby/ByteStash/releases/tag/v1.6.2
- github.comhttps://github.com/jordan-dalby/ByteStash/security/advisories/GHSA-26m9-ww2j-3cr5
- www.vulncheck.comhttps://www.vulncheck.com/advisories/bytestash-1.5.10-before-1.6.2-insufficient-session-expiration-via-api-keys
CVECVSSEPSSKEVRExploitTítuloMod.
CVE-2026-1260764.2 MÉD24.1%
——7Action 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.1dCVE-2026-111243—3.6%
——1A 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.1dCVE-2026-1238137.5 ALT18.1%
——5pyLoad 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.2dCVE-2026-1238046.8 MÉD31.0%
——9SuperTokens 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.2dCVE-2026-1237997.4 ALT56.4%
——17SuperTokens 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.2dCVE-2026-1064667.5 ALT22.7%
——7The 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.1d