EEF-CVE-2026-119215: AshAuthentication TOTP setup lets a user install their own authenticator secret on another user's account

Summary

Authorization Bypass Through User-Controlled Key vulnerability in team-alembic ashauthentication 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 confirmsetup 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 ashauthentication: from 5.0.0-rc.0 before 5.0.0-rc.16.

Workarounds

Do not expose setup or confirmsetup on a record the caller chooses. Call them through AshAuthentication.Strategy.Totp.Actions with the signed-in user, as the built-in routes do.

Configurations

An application exposes the TOTP setup or confirmsetup action on a record the caller identifies, for example through AshJsonApi, AshGraphql or a controller that passes a looked-up user to AshAuthentication.Strategy.Totp.Actions.confirmsetup/3, and the attacker can read the victim's user record. Installing the attacker's secret requires confirmsetupenabled? true; signing in with it alone requires signinenabled? true. The routes AshAuthentication and AshAuthenticationPhoenix provide always use the signed-in user and are not affected.