AshAuthentication EUVD-2026-116024

Exploitation requires that the application expose the TOTP 'setup' or 'confirm_setup' action on a record the caller identifies (for example through AshJsonApi, AshGraphql, or a custom controller that passes a looked-up user to AshAuthentication.Strategy.Totp.Actions.confirm_setup/3) AND that the attacker, an authenticated account holder (PR:L), can read the victim's user record. Signing in as the victim additionally requires sign_in_enabled? true; without it the attacker only holds the victim's second factor. Key limiting factors: the built-in AshAuthentication and AshAuthenticationPhoenix routes always operate on the signed-in user and are NOT exploitable; only pre-release versions 5.0.0-rc.0 through 5.0.0-rc.15 are affected; and a read policy restricting users to their own record (when the action is reached through AshJsonApi/AshGraphql, which load the record via that policy before the action runs) blocks the attack.

This is a genuine but conditional account-takeover flaw, not inflated severity. The authoritative signal is the vendor/CNA-provided CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N, score 7.6): network-reachable, low complexity once reachable, requiring an authenticated low-privilege user (PR:L) and a present attack requirement (AT:P) that maps to the non-default exposure of the TOTP setup/confirm_setup actions. Confidentiality and integrity impact are High (an attacker can plant a TOTP secret they control on a victim's record and then sign in as that victim or hold their second factor), with no availability impact (VA:N). Exploitation is confirmed no-public-exploit: no CISA KEV listing and no EPSS value were supplied, and the references are the advisory plus fix commits, not proof-of-concept code - so there is no public exploit identified at time of analysis and no evidence of active exploitation. The vuln.today decision label is 'this_week', consistent with a serious authorization bypass that is gated behind specific deployment exposure rather than an emergency. Two caveats to state explicitly: (1) the flaw only affects applications that expose the setup/confirm_setup actions on a caller-chosen record (e.g. via AshJsonApi, AshGraphql, or a custom controller) - the built-in AshAuthentication/AshAuthenticationPhoenix routes always use the signed-in user and are NOT affected, so real-world exposure depends heavily on how the integrator wired these actions; (2) only pre-release 5.0.0-rc.0 through 5.0.0-rc.15 are affected, which further narrows the exposed population. EPSS is absent (not an error); its absence plus no KEV supports treating this as patch-this-week rather than drop-everything.

An authenticated low-privilege user of an Ash application that has exposed the TOTP setup/confirm_setup actions by record key (e.g. through AshJsonApi or AshGraphql) and can read another user's record calls setup against the victim's record, receiving the victim's pending secret and setup token, then calls confirm_setup to install an attacker-controlled TOTP secret onto the victim's account. With sign_in enabled, the attacker then logs in as the victim using the victim's email plus an attacker-generated code; otherwise the attacker permanently holds the victim's second factor. No public exploit code was identified at time of analysis.