CVE-2026-88952
CriticalCVSS 9.1Exploitation Probability (EPSS)
Low risk37th percentile - higher than 37% of all known CVEs
Summary
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.
Risk Assessment
Risk of account takeover by an attacker, potentially leading to unauthorized data access and actions on behalf of the victim.
Recommendation
Update ash_authentication to a fixed version (4.15.0 or later for 4.x series and 5.0.0-rc.14 or later for 5.x) to resolve the issue.
Other vulnerabilities in ash_authentication
See all- CVE-2026-76949Critical
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.
- 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-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)
Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker to be signed in as another user by linking an OAuth2 identity to an account that is not theirs. AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3 matches an existing account using the register action's upsert_identity keys, then gates linking the incoming provider identity to it on email_trusted?/2, which reads only the provider's email_verified boolean and never compares the provider's email value with the matched account's email. That gate assumes the account was matched by its email field, so under any other upsert_identity it is vacuous and an attacker presenting their own verified email is attached to, and issued a session for, an account matched on some other attribute. The same unguarded gate applies in OAuth2.SignInPreparation on the registration_enabled? false path, where the account is matched by the sign-in action's read filter instead. The upsert also rewrites the matched account's email to the attacker's address, so later account recovery reaches the attacker rather than the owner. This issue affects ash_authentication: from 4.14.0 before 4.15.0 and from 5.0.0-rc.10 before 5.0.0-rc.14.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS