CVE-2026-119215 in ash_authentication
Summary
by MITRE • 11/03/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/03/2026
The vulnerability identified as an Authorization Bypass Through User-Controlled Key in the AshAuthentication library, specifically within the team-alembic implementation of ash_authentication, represents a critical flaw in how multi-factor authentication setup processes are validated and applied to user records. This issue allows an authenticated attacker with their own account to manipulate the two-step verification process for other users by installing a Time-based One-Time Password secret that they control onto another victim's account. Once this malicious configuration is successfully applied, the attacker can either sign in as the compromised user or intercept their second-factor authentication codes, effectively neutralizing one of the primary security controls designed to protect accounts from unauthorized access.
The technical root cause lies within the AshAuthentication.Strategy.Totp.ConfirmSetupChange function and related change management functions such as GeneratePendingSetupChange and GenerateSecretChange. These functions are responsible for handling the lifecycle of TOTP setup changes, including generating pending secrets and confirming them upon user verification. The critical flaw is that while these functions verify the validity of a setup token to ensure it matches an existing request, they fail to validate that the token was originally issued to the specific record being confirmed. This missing check creates a race condition or logic error where an attacker can submit their own pending secret and associated setup token against a different user's account identifier. Because the system only checks if the token is valid for any change rather than specifically for the target record, it accepts the confirmation request as legitimate.
Furthermore, the vulnerability is exacerbated by how AshAuthentication handles policy enforcement during these operations. The functions involved in generating and confirming setup changes mark their respective changesets with a flag indicating they are internal AshAuthentication interactions. This designation triggers a bypass mechanism within the standard AshAuthenticationInteraction policy, which typically allows certain administrative or system-level actions to proceed without full user context validation. Consequently, even if an application developer has implemented strict policies intended to restrict TOTP setup and confirmation operations so that users can only modify their own records, these safeguards are circumvented when the actions are exposed via record key. The bypass mechanism effectively ignores the actor's identity relative to the target resource, allowing a direct API call on another user's record to return that user's pending secret and setup token without triggering the expected authorization checks.
From an industry standard perspective, this vulnerability aligns with CWE-285: Improper Authorization, as the application fails to enforce proper access controls when users attempt to perform actions upon resources they do not own. Additionally, it relates to CWE-640: Weak Password Recovery Mechanism for Forgotten Password and CWE-384: Session Fixation in the context of multi-factor authentication bypasses, where an attacker takes control of a session or account by manipulating the verification process. In terms of MITRE ATT&CK framework tactics, this behavior facilitates Account Manipulation (T1098) specifically through Registered Email Domain Control or similar mechanisms to hijack identity attributes, and potentially Credential Access (T1110) if the attacker uses the stolen TOTP codes for brute force or phishing attacks. The operational impact is severe, as it undermines the integrity of two-factor authentication, a cornerstone of modern security architectures, allowing attackers to bypass MFA protections entirely by controlling both sides of the verification handshake.
Mitigation strategies must focus on enforcing strict ownership validation at every step of the TOTP setup lifecycle. Developers should ensure that when confirming a setup change or generating pending secrets, the system explicitly verifies that the actor initiating the request is the same entity as the owner of the target user record. This requires passing and validating the authenticated user's unique identifier against the resource key in all relevant API endpoints and internal functions. Additionally, applications relying on AshAuthentication should upgrade to version 5.0.0-rc.16 or later, where this logic error has been addressed by ensuring that setup tokens are bound strictly to their originating records. Until an update is applied, administrators can implement custom policy checks in their application layer that explicitly validate record ownership before allowing any TOTP-related actions to proceed, thereby closing the bypass gap created by the library's internal interaction flags.