Authentication Bypass by Spoofing vulnerability in team-alembic AshAuthentication allows account takeover of local users via OAuth2/OIDC sign-in.

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address (an upsert on the email field, or a user-defined sign-in filter) rather than by the OpenID Connect iss/sub claim combination. Per OpenID Connect Core §5.7, only iss/sub uniquely and stably identifies an end-user; other claims, including email, MUST NOT be used as unique identifiers.

A provider login presenting a victim's email, including an unverified email, a reused email, or an account with email_verified: false, resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email (or who benefits from provider-side email reuse or reclamation) obtains the victim's full local privileges.

The fix resolves users by the (strategy, sub) identity stored in a user identity resource, and only links a new sub to an existing local account by email when the provider's email_verified claim is trusted (trust_email_verified?).

This issue affects ash_authentication from 0.1.0 before 4.14.0 and from 5.0.0-rc.0 before 5.0.0-rc.10.

Affected: Hex: ash_authentication

### Summary

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect `iss`/`sub` claim combination. A provider login presenting a victim's email (including an unverified, reused, or `email_verified: false` account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.

### Details

Per OpenID Connect Core §5.7, only the `iss`/`sub` claim combination uniquely and stably identifies an end-user; any other claim, including `email`, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (`upsert_identity` on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.

**1. Provider login.** The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.

**2. AshAuthentication register step.** `'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3` invokes the upsert action whose `upsert_identity` resolves on the email. The action lands on the victim's existing record.

**3. Sign-in preparation.** `'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3` d…