# AshAuthentication vulnerable to OAuth2/OIDC account takeover via email-based user matching

AshAuthentication OAuth2/OIDC strategies matched local users by email instead of iss/sub, letting an attacker register a provider account with a victim's email and take over their local account.

- Payout: Research
- Severity: critical
- Program: AshAuthentication
- Found by (vendor credit): Jarl André Hübenthal, Jonatan Männchen / EEF
- Found by: jarlah
- Disclosed: 2026-08-25
- CVE: CVE-2026-49757
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-777c-2fxx-qr28
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-777c-2fxx-qr28
- Tags: area:web domain:web impact:ato impact:privesc kind:research platform:ghsa sev:critical tech:oauth tech:oidc technique:source-review vuln:account-takeover vuln:auth-bypass

**Target:** OAuth2/OIDC authentication strategy in Elixir AshAuthentication library
**Root cause:** The OAuth2 register flow upserted users on the email field (upsert_identity on email or a user-defined sign-in filter) and SignInPreparation never verified the returned user against an iss/sub identity, violating OIDC Core §5.7 which requires iss/sub as the unique identifier.
**Steps:**
1. Register an account on any accepted OAuth/OIDC provider using the victim's email (or exploit email reclamation on a provider that allows reuse).
2. Complete the standard OAuth flow against the AshAuthentication application.
3. `AshAuthentication.Strategy.OAuth2.IdentityChange:change/3` invokes the upsert action whose `upsert_identity` resolves on email, landing on the victim's existing record.
4. `AshAuthentication.Strategy.OAuth2.SignInPreparation:prepare/3` does not check iss/sub, so the attacker is authenticated as the victim and receives a session token for the victim's account.
**How found:** Reporter observed that the OAuth2/OIDC register flow drove the upsert by email rather than the iss/sub claim pair mandated by OIDC Core §5.7, and that SignInPreparation never re-verified the returned user against an iss/sub identity.
**Exploitation:** Attacker needs only an account on a configured OAuth/OIDC provider that does not strictly verify email ownership (Slack, generic OIDC, custom OAuth2) or that permits email reclamation. After registering with the victim's email and completing the OAuth flow, the email-based upsert resolves to the victim's local record and the attacker obtains a session token with the victim's full privileges.
**Insight:** When auditing OAuth/OIDC integrations, check what field the account-linking/upsert keys on: any email-based matching is exploitable via providers that don't verify email ownership or allow email reclamation, even if the app's primary provider is strict.