CVE-2026-86533 in ash_authentication
Summary
by MITRE • 09/17/2026
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_phoenix: from 2.10.0 before 2.17.4 and from 3.0.0-rc.0 onward; ash_authentication: from 4.9.1 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in AshAuthentication and its Phoenix integration represents a critical failure in session management logic, specifically regarding the handling of revoked sessions. This flaw allows an attacker or malicious actor to maintain active authentication privileges even after a user has explicitly signed out or when their access rights have been formally revoked by administrative action. The root cause lies in the architectural separation between how sessions are stored and how they are validated during subsequent requests. When a resource is configured with session_identifier set to jti (JWT ID) and require_token_presence_for_authentication? is disabled, the system stores the session value as just the subject identifier rather than including the full token structure that contains the unique JTI. This design choice was intended to facilitate specific revocation mechanisms but inadvertently creates a blind spot in the authentication verification process for standard cookie-based or non-token-presence sessions.
The technical flaw manifests within two primary entry points: AshAuthentication.Plug.Helpers.authenticate_resource_from_session/4 and AshAuthentication.Phoenix.LiveSession.on_mount/4. Both functions utilize split_identifier/2 to parse the session data, but in doing so, they discard the JTI component entirely before passing only the bare subject identifier to AshAuthentication.subject_to_user/3 for user record reloading. This process completely bypasses any check against a revocation database or blacklist because the unique token identifier required to query such records is no longer present in the context of the authentication decision. Consequently, while the system correctly checks tokens when require_token_presence_for_authentication? is enabled by calling AshAuthentication.TokenResource.Actions.get_token/3 with both the JTI and purpose, this safeguard does not apply to the standard session flow where only the subject ID is retained.
From an operational impact perspective, this vulnerability undermines the fundamental security principle of immediate access termination upon logout or revocation. If a user signs out from one device while remaining logged in on another, or if an administrator revokes a specific session due to suspected compromise, that revoked session remains fully functional until it naturally expires based on its initial TTL settings rather than being invalidated immediately by the revocation record. This creates a window of opportunity for unauthorized access using captured session identifiers, effectively rendering logout mechanisms and manual revocation controls ineffective against persistent threats or insider abuse scenarios where immediate session termination is required.
This issue maps directly to CWE-613, Insufficient Session Expiration, as the application fails to properly invalidate sessions after they are no longer needed or when their validity has been explicitly revoked by security policy. Furthermore, it aligns with MITRE ATT&CK technique T1528, Steal Application Access Token, in scenarios where an attacker captures a session identifier prior to revocation and continues to use it despite the intended invalidation. The lack of real-time validation against a central revocation store means that the system relies solely on local state expiration rather than authoritative access control checks for every request.
Mitigation strategies must focus on ensuring that all authentication paths, regardless of whether they rely on token presence or standard session cookies, consult the centralized revocation mechanism before granting access. Developers should modify authenticate_resource_from_session and LiveSession.on_mount to retrieve and validate the JTI against a revoked tokens table even when require_token_presence_for_authentication is disabled. Alternatively, storing the full signed token in the session allows for consistent validation logic across all authentication methods. Until patched, administrators can implement additional controls such as shorter session TTLs or IP-binding checks to reduce the window of exposure, though these are compensatory measures rather than fixes for the underlying architectural flaw.
The vulnerability affects specific versions of ash_authentication_phoenix from 2.10.0 up to but not including 2.17.4, and from 3.0.0-rc.0 onward without an upper bound in this context. Similarly, it impacts ash_authentication library versions starting from 4.9.1 through 4.15.0 (exclusive) and all releases of the 5.0.0 release candidate series prior to rc.14. Users operating within these version ranges are strongly advised to upgrade immediately to resolve this session management deficiency and restore proper revocation enforcement capabilities.