Summary
AshAuthentication vulnerable to OAuth2/OIDC account takeover via email-based user matching
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 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.
Configurations
Exploitation requires one of:
- The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
- The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.
Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.
PoC
- On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
- Complete the standard OAuth flow against the AshAuthentication application.
- The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.
References
- Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
- Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
- Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7
Impact
Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
ash_authentication to 4.14.0 or later; ash_authentication to 5.0.0-rc.10 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-49757? CVE-2026-49757 is a critical-severity security vulnerability in ash_authentication (erlang), affecting versions >= 0.1.0, < 4.14.0. It is fixed in 4.14.0, 5.0.0-rc.10.
- Which versions of ash_authentication are affected by CVE-2026-49757? ash_authentication (erlang) versions >= 0.1.0, < 4.14.0 is affected.
- Is there a fix for CVE-2026-49757? Yes. CVE-2026-49757 is fixed in 4.14.0, 5.0.0-rc.10. Upgrade to this version or later.
- Is CVE-2026-49757 exploitable, and should I be worried? Whether CVE-2026-49757 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-49757 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-49757?
- Upgrade
ash_authenticationto 4.14.0 or later - Upgrade
ash_authenticationto 5.0.0-rc.10 or later
- Upgrade