CVE-2026-88952: OAuth2 sign-in attached to an existing account without an email comparison in AshAuthentication
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 upsertidentity keys, then gates linking the incoming provider identity to it on emailtrusted?/2, which reads only the provider's emailverified 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 upsertidentity 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 registrationenabled? 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 ashauthentication: from 4.14.0 before 4.15.0 and from 5.0.0-rc.10 before 5.0.0-rc.14.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 4.15.0 - Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 5.0.0-rc.14 - Operational
Review affected accounts and the relevant AshAuthentication register/sign-in flows that used OAuth2 identity linking. Check affected accounts for rewritten email addresses (victim email may have been rewritten to the attacker’s address).
- Operational
For operators whose register action or sign-in action matched anything other than the email, review UserIdentity rows for links whose provider email does not match the linked account's email, and remediate those improperly linked identities.
Event History
Frequently Asked Questions
Which deployments are exposed to account takeover?
Deployments are exposed when OAuth2 account resolution can match an existing account using upsert_identity keys other than that account's email, or when the registration-disabled sign-in path matches an account through the sign-in action's read filter. In those cases, the email-verification check does not confirm that the OAuth2 provider email belongs to the matched account.
What does an attacker need to exploit this issue?
The attacker needs an OAuth2 identity from a provider that reports the attacker's email as verified, and a way for the application’s configured identity matching or sign-in filter to resolve that sign-in to another user's account. The attacker does not need the victim account's email to match the provider email.
What is the impact after a successful sign-in?
The attacker is linked to the matched account and issued a session for it. The account email is also rewritten to the attacker's email address, which can direct subsequent account-recovery messages to the attacker.
Are configurations with registration disabled affected?
Yes. The same unguarded email-trust gate applies when registration is disabled and the account is matched using the sign-in action's read filter.