CVE-2026-88952 in ash_authentication
Summary
by MITRE • 09/17/2026
Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker to be signed in as another user by linking an OAuth2 identity to an account that is not theirs.
AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3 matches an existing account using the register action's upsert_identity keys, then gates linking the incoming provider identity to it on email_trusted?/2, which reads only the provider's email_verified boolean and never compares the provider's email value with the matched account's email. That gate assumes the account was matched by its email field, so under any other upsert_identity it is vacuous and an attacker presenting their own verified email is attached to, and issued a session for, an account matched on some other attribute. The same unguarded gate applies in OAuth2.SignInPreparation on the registration_enabled? false path, where the account is matched by the sign-in action's read filter instead. The upsert also rewrites the matched account's email to the attacker's address, so later account recovery reaches the attacker rather than the owner.
This issue affects ash_authentication: from 4.14.0 before 4.15.0 and from 5.0.0-rc.10 before 5.0.0-rc.14.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in AshAuthentication, specifically within the OAuth2 authentication strategy, represents a critical failure in identity verification logic that allows for account takeover through improper authentication mechanisms. This flaw stems from an incorrect assumption made by the application regarding how user accounts are matched against incoming provider identities during the registration and sign-in processes. The core issue lies in the implementation of the email_trusted?/2 function within AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3, which serves as a gate to determine whether an incoming OAuth identity can be linked to an existing local account. This function relies exclusively on checking if the provider's email_verified boolean is true, without performing any validation that the email address provided by the OAuth provider actually matches the email address associated with the matched local account.
In typical secure implementations of OAuth flows, it is imperative to verify that the identity claimed by the third-party provider corresponds exactly to the user record in the application database. However, under this vulnerability, if an attacker presents a valid, verified email from their own OAuth provider, and there exists any existing account in the system where upsert_identity keys or read filters match on attributes other than email—such as username, phone number, or external ID—the gate remains open. Consequently, the application incorrectly associates the attacker's authenticated session with an unrelated victim's account. This bypasses standard authentication controls because the system trusts the provider's verification status without confirming identity continuity between the local record and the remote assertion.
The operational impact of this vulnerability is severe, extending beyond simple unauthorized access to include persistent data manipulation and potential long-term compromise of user accounts. When the flawed linking logic executes, it not only assigns a session for an account that does not belong to the attacker but also actively rewrites the victim's email address field in the database to match the attacker's verified email from the OAuth provider. This action effectively hijacks the account ownership metadata. As a result, any future password reset or account recovery procedures will send verification links and notifications to the attacker rather than the legitimate owner. This transforms a transient authentication bypass into a persistent takeover scenario where the original user is locked out of their own account while the attacker maintains control through email-based recovery mechanisms.
This technical flaw maps directly to CWE-287, which describes Improper Authentication, specifically highlighting failures in verifying identity claims during multi-factor or third-party integration contexts. Furthermore, from an offensive security perspective aligned with MITRE ATT&CK frameworks, this behavior facilitates Account Manipulation and potentially Initial Access through credential stuffing or social engineering if combined with other vectors, as the attacker can manipulate account recovery channels to maintain persistence. The vulnerability affects specific versions of the AshAuthentication library, namely those ranging from 4.14.0 up to but not including 4.15.0, and from 5.0.0-rc.10 up to but not including 5.0.0-rc.14. Developers utilizing these versions must upgrade immediately to mitigate the risk of unauthorized account linkage and subsequent data exfiltration or denial of service through account lockout.