CVE-2026-76949
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk41th percentile - higher than 41% of all known CVEs
Summary
A vulnerability in the ash_authentication library (Elixir) allows an attacker who can plant a remember-me cookie in a victim's browser to replace the victim's authenticated session with one for the attacker's own account. The issue stems from a mismatch between the session keys used by the guard and the reader, causing remember-me sign-in to run on every request.
Risk Assessment
An attacker can hijack the victim's session and capture data entered after login, leading to confidentiality and integrity breaches.
Recommendation
Update ash_authentication to version 4.15.0 or 5.0.0-rc.14 (or later) and review the require_token_presence_for_authentication? configuration.
Other vulnerabilities in ash_authentication
See all- CVE-2026-91039Critical
Vulnerability in ash_authentication related to dynamic_oidc strategy that fails to maintain proper identity namespace separation across connections. An attacker controlling one connection can be signed in as a local user created through a different connection because user identities are not correctly separated.
- CVE-2026-88952Critical
In ash_authentication there is an improper authentication vulnerability that allows an attacker to sign in as another user by linking their OAuth2 identity to an account that is not theirs. The attacker can attach a verified email to an account matched on other attributes, leading to session hijacking.
- CVE-2026-110826Medium
In team-alembic ash_authentication with apply_on_password_change enabled, the password change condition is evaluated before the new hash is set in a before_action hook, so stored tokens are not revoked for non-atomic password changes. An attacker holding a victim's session token stays signed in after the victim resets or changes their password.
- CVE-2026-119215High
Authorization Bypass Through User-Controlled Key vulnerability in team-alembic ash_authentication allows a user with an account to install a TOTP secret they control on another user's account, and then sign in as that user or hold their second factor. AshAuthentication.Strategy.Totp.ConfirmSetupChange verified a setup token but did not check that it was issued to the record being confirmed, so an attacker's own pending secret could be confirmed onto another user's record. The TOTP setup changes, ConfirmSetupChange, GeneratePendingSetupChange and GenerateSecretChange, also marked their changesets as AshAuthentication interactions, which the standard AshAuthenticationInteraction policy bypass lets through. A policy limiting setup and confirm_setup to the actor's own record therefore never ran when an application exposed those actions by record key, and a direct setup call on another user's record returned that user's pending secret and setup token. This issue affects ash_authentication: from 5.0.0-rc.0 before 5.0.0-rc.16.
- CVE-2026-118505Medium
The ash_authentication library (team-alembic project) contains an improper restriction of excessive authentication attempts vulnerability, allowing an unauthenticated attacker to guess passwords and one-time passwords without limit. The password, magic link and OTP strategies add brute_force_strategy preparation only to the actions they generate, so when a resource defines its own action the limit is not applied; additionally, with registration_enabled? true the OTP sign-in is a create action on which preparations do not run. The issue affects versions from 5.0.0-rc.4 before 5.0.0-rc.16.
- CVE-2026-86688High
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.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS