CVE-2026-119215
AshAuthentication TOTP setup lets a user install their own authenticator secret on another user's account
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.
Fixes and workarounds
Workaround
Do not expose setup or confirm_setup on a record the caller chooses. Call them through AshAuthentication.Strategy.Totp.Actions with the signed-in user, as the built-in routes do.
Source: CNA: EEFFix
The reporting source identifies this reference as a patch. Check the advisory for affected versions and supported release branches.
Source: CNA: EEFAffected products and versions
| Product | Versions | Authority |
|---|---|---|
| ash_authentication team-alembic ash_authentication
hex |
≥ 5.0.0-rc.0; < 5.0.0-rc.16 (affected, semver)
Other versions: unaffected |
CNA: EEF |
| ash_authentication team-alembic team-alembic/ash_authentication
github |
≥ 6e7a880698614887527a87df206b4eb0c0fbd8c1; < 4058be0f519c2e9b0d2266e90f9c7d8547d54574 (affected, git)
Other versions: unaffected |
CNA: EEF |
Version ranges are source assertions. Check the vendor advisory and your installed configuration before determining exposure.
CVSS assessments
| Version / score | Vector | Authority |
|---|---|---|
| 4.0 / 7.6 high |
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 | CNA: EEF |
Exploit evidence
No exploit evidence in collected sources. This is not proof of no exploitation.
References
- https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-gx67-694c-655cCNA: EEF · vendor-advisory, related
- https://cna.erlef.org/cves/CVE-2026-119215.htmlCNA: EEF · related
- https://osv.dev/vulnerability/EEF-CVE-2026-119215CNA: EEF · related
- https://github.com/team-alembic/ash_authentication/commit/6e7a880698614887527a87df206b4eb0c0fbd8c1CNA: EEF · related
- https://github.com/team-alembic/ash_authentication/commit/4058be0f519c2e9b0d2266e90f9c7d8547d54574CNA: EEF · patch
For agents and automation
Read public disclosures for free as Markdown or JSON. Compatible browsers also expose native WebMCP tools to search disclosures, read this page, and discover API access.
Use the ontology-linked Cyber API with x402 pay per request, or a Y2 Pro or Elite API key with the intel:cyber scope.
Endpoints and access details
https://api.y2.dev/api/v2/cyber/cveshttps://api.y2.dev/api/v2/cyber/cves/{cveId}
A workspace owner or admin can create a Pro or Elite API key. Send Authorization: Bearer <Y2_API_KEY> from your trusted agent runtime.
For x402, omit Authorization and read the HTTP 402 payment challenge before signing a retry. Public browser tools do not make payments.