CVE-2026-88952

## Summary 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. ## Impact An attacker who controls a provider account with a verified email of their own is signed in as a different local user, holding a session bearing that user's subject, with no interaction from the victim and no need to pre-register. Because the link also rewrites the matched account's email to the attacker's address, account recovery for the victim is redirected to the attacker and the compromise survives the provider identity being unlinked. ## Workarounds Set `trust_email_verified? false` on the affected strategy, which refuses the sign-in rather than linking it and closes both the register and the sign-in path. Alternatively, key the register action's `upsert_identity`, or the sign-in action's read filter, on the email attribute, which restores the premise the gate assumes. ## Configurations The strategy must have `trust_email_verified?` enabled, and the account must be matched on something other than the email: a register action whose `upsert_identity` keys are not the email attribute, or, with `registration_enabled? false`, a sign-in action whose read filter is not the email. `trust_email_verified?` defaults to `false` on the base `oauth2` strategy, but the `apple`, `auth0`, `github`, `google` and `slack` strategies each set it to `true` in their own DSL. ## Solutions Upgrading prevents new links but does not unpick existing ones. An account already linked through this path stays linked, and a victim's email may already have been rewritten to the attacker's address. Operators whose register action or sign-in action matched on anything other than the email should review their `UserIdentity` rows for links whose provider email does not match the linked account's email, and check affected accounts for a rewritten email address.