CVE WatchNov 10, 2026

CVE-2026-126076

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 wr

CVSS

4.2

Medium

EPSS

—

KEV

—

Exploit Today

—

0-100

Published: Nov 10, 2026 · Last modified: Nov 10, 2026 · CWE-613

EPSS · 30d

Not enough EPSS history yet.

Technical description

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.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-111243—

—

——0A 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.14h CVE-2026-1238137.5 HIG

18.0%

——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.1d CVE-2026-1238046.8 MED

30.9%

——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.1d CVE-2026-1237997.4 HIG

56.3%

——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.1d CVE-2026-1064667.5 HIG

22.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.13h CVE-2026-113508—

12.2%

——4Apache 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.9h