CVE-2026-76949 in ash_authentication
Summary
by MITRE • 09/18/2026
Authentication Bypass by Spoofing vulnerability in team-alembic ash_authentication allows an attacker who can plant a remember-me cookie in a victim's browser to replace that victim's authenticated session with one for the attacker's own account.
AshAuthentication.Plug.Helpers.sign_in_using_remember_me/3 skips re-authenticating an already-signed-in visitor by checking the session for "<subject_name>_token", but store_in_session/2 writes that key only when require_token_presence_for_authentication? is enabled and otherwise writes the bare subject name. At the default setting the guard therefore reads a key that is never written, its already-signed-in branch is unreachable, and the remember-me sign-in runs on every request through the per-request browser pipeline plug. A planted remember-me cookie is consequently honoured even for a visitor holding a live authenticated session, so whatever the victim enters afterwards lands in data the attacker controls. The read path in authenticate_resource_from_session/4 selects the key correctly, so the guard and the reader disagree about which key holds the session.
This issue affects ash_authentication: from 4.10.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in AshAuthentication represents a critical authentication bypass mechanism rooted in an inconsistency between session token generation and validation logic within the remember-me functionality. This flaw allows an attacker who possesses the ability to inject or plant a specific cookie into a victim's browser environment to hijack the authenticated session of that user. The core technical failure lies in the asynchronous behavior of two distinct functions: sign_in_using_remember_me/3 and store_in_session/2. When a system operates under its default configuration, where require_token_presence_for_authentication is disabled, the store function writes only the bare subject name to the session rather than generating or storing a specific token key expected by other parts of the authentication pipeline. This discrepancy creates a state mismatch where the guard condition in sign_in_using_remember_me/3 checks for a key named with a suffix such as _token which is never actually written under default settings, rendering the branch that prevents re-authentication unreachable and effectively disabled.
Consequently, every request processed through the per-request browser pipeline plug triggers the remember-me sign-in logic regardless of whether the user already holds a valid authenticated session. This architectural flaw means that if an attacker successfully plants their own remember-me cookie into the victim's browser, the system will honor this planted credential on subsequent requests, effectively replacing the victim's legitimate session with one associated with the attacker's account. The read path within authenticate_resource_from_session/4 correctly identifies and selects the appropriate key for validation, but because the write path diverges from what the guard expects under default configurations, the security control fails to recognize that a user is already authenticated. This leads to an overwrite of the session state, allowing any data entered by the victim after the cookie injection to be captured or controlled by the attacker who now holds the active session context.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-384 Session Fixation, as it involves manipulating session identifiers to hijack user identity without proper re-authentication checks. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts and specifically leverages techniques related to session manipulation where an adversary uses existing valid credentials or planted tokens to maintain access. The impact is severe as it compromises the integrity of the authentication process, potentially leading to unauthorized data access, privilege escalation, or further exploitation depending on the victim's role within the application.
The vulnerability affects versions of ash_authentication ranging from 4.10.0 up to but not including 4.15.0 and from 5.0.0-rc.0 up to but not including 5.0.0-rc.14. Mitigation strategies should focus on ensuring consistency between session write operations and read validations, particularly regarding the require_token_presence_for_authentication setting. Administrators are advised to upgrade to patched versions where this logic has been corrected to prevent the unreachable guard condition from being bypassed. Additionally, implementing strict cookie security attributes such as HttpOnly, Secure, and SameSite can help mitigate the risk of cookie planting attacks by restricting how browsers handle cross-site or maliciously injected cookies, thereby reducing the attack surface for session hijacking attempts.