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.
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
erlang/ash_authenticationto a version that resolves this vulnerability.Fixed in 5.0.0-rc.16 - Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 5.0.0-rc.16 - Configuration
Call setup and confirm_setup through AshAuthentication.Strategy.Totp.Actions with the signed-in user, as the built-in routes do; do not expose either action on a record selected by the caller.
AshAuthentication TOTP setup setup and confirm_setup record exposure = signed-in user only
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using ash_authentication from 5.0.0-rc.0 before 5.0.0-rc.16 are affected when they expose the TOTP setup or confirmation actions against a record selected by the caller.
What does an attacker need to exploit this?
The attacker needs an account and the ability to invoke setup or confirm_setup for another user's record. Policies intended to restrict these actions to the actor's own record may not protect the action because the relevant changesets are treated as AshAuthentication interactions.
How can I tell whether my application has a vulnerable exposure?
Review whether setup or confirm_setup can be called with a user record key chosen by the requester. A direct setup call against another user's record returning that user's pending secret and setup token indicates the exposed behavior described by this issue.
What can be done if updating is not immediately possible?
Do not expose setup or confirm_setup on a record selected by the caller. The workaround is to invoke these actions through the AshAuthentication TOTP strategy rather than through a caller-selected record.