CVE-2026-86688 in ash_authentication
Summary
by MITRE • 09/18/2026
Session Fixation vulnerability in team-alembic ash_authentication allows an attacker who can plant a session identifier in a victim's browser to hold an authenticated session once that victim signs in.
AshAuthentication.Plug.Helpers.store_in_session/2 writes the authenticated subject into the existing session with Plug.Conn.put_session/3 and never calls Plug.Conn.configure_session(renew: true), so the identifier the visitor arrived with carries into their authenticated session. Every authentication event reaches this one function: the default success/4 injected by AshAuthentication.Phoenix.Controller.__using__/1, the AuthController emitted by mix ash_authentication_phoenix.install, and remember-me auto-login. AshAuthentication.Phoenix.Plug.store_in_session/2 is a defdelegate to it. Logout does not close the window either, because clear_session/2 ends with Plug.Conn.clear_session/1, which clears session contents but leaves the identifier intact, so a planted identifier survives a logout-then-login cycle.
This issue affects ash_authentication: from 0.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The identified vulnerability constitutes a session fixation flaw within the AshAuthentication library for Elixir applications, specifically affecting versions ranging from 0.2.0 up to but not including 4.15.0 and version 5.0.0-rc.0 through 5.0.0-rc.13. This security defect arises because the authentication mechanism fails to rotate or regenerate the session identifier upon successful user login, thereby allowing an attacker who has previously planted a specific session cookie in a victim's browser to hijack that same session once the victim authenticates themselves. The core technical failure lies within the AshAuthentication.Plug.Helpers.store_in_session/2 function, which is responsible for persisting authenticated subject data into the existing Plug.Conn context using put_session/3 without subsequently invoking configure_session with the renew option set to true. Consequently, the session identifier that was present during the initial unauthenticated request remains unchanged and valid after the authentication process completes, effectively binding the attacker's chosen session ID to the victim's privileged account state.
The operational impact of this vulnerability is severe as it enables unauthorized access to user accounts without requiring password theft or credential compromise. An attacker can initiate a fixation attack by directing a target to a malicious link that sets a known session cookie in their browser, such as via cross-site scripting or phishing. When the victim subsequently logs into the application using valid credentials, the server accepts this pre-existing session identifier and associates it with the authenticated user's profile. This allows the attacker to simply use the same session ID they planted earlier to impersonate the victim across all subsequent requests until the session expires or is manually invalidated by administrative action. The vulnerability persists through standard logout procedures because the clear_session/2 function, which handles session termination, relies on Plug.Conn.clear_session/1 that removes session data contents but deliberately preserves the underlying session identifier cookie in the client's browser environment. This design choice means that a cycle of logging out and then logging back in does not mitigate the risk if an attacker has already fixed the session ID prior to the victim's initial login attempt.
From a classification perspective, this vulnerability aligns with CWE-384, which describes Session Fixation attacks where an application fails to invalidate or regenerate session identifiers after authentication events. In terms of offensive security frameworks, this behavior corresponds to MITRE ATT&CK technique T1078, specifically the Valid Accounts sub-technique, as it allows attackers to leverage legitimate credentials by manipulating the session management layer rather than breaking cryptographic protections directly. The flaw is systemic within the library's default authentication flows, impacting every entry point that utilizes store_in_session/2 for persisting authenticated state, including success handlers injected by AshAuthentication.Phoenix.Controller._using_/1, custom AuthController implementations generated during installation, and automatic remember-me login mechanisms.
To mitigate this vulnerability, application developers must upgrade the ash_authentication dependency to version 4.15.0 or later, where the session regeneration logic has been corrected to ensure that a new session identifier is issued upon successful authentication. For applications unable to immediately upgrade, a manual workaround involves implementing custom plug middleware that explicitly calls Plug.Conn.configure_session(conn, renew: true) after verifying user credentials and before storing any authenticated data in the session store. Additionally, developers should review their logout implementations to consider whether clearing the session cookie entirely is more appropriate than preserving it for remember-me functionality, or ensure that even if the identifier persists post-logout, a fresh login event triggers an immediate regeneration of that identifier. Regular security audits focusing on session management practices and adherence to OWASP guidelines regarding session fixation prevention are recommended to maintain robust authentication hygiene across Elixir-based web applications utilizing this library.