AshAuthentication OAuth2/OIDC Flaw Allowed Account Takeover via Email Matching (CVE-2026-49757)

A newly published GitHub Security Advisory (GHSA-777c-2fxx-qr28, CVE-2026-49757) discloses an unauthenticated account-takeover vulnerability in AshAuthentication, the Elixir authentication library, affecting its OAuth2 and OIDC strategies. A public proof-of-concept accompanies the disclosure.

What was reported

According to the advisory, AshAuthentication's OAuth2/OIDC register and sign-in flows resolved local user accounts by matching the provider-supplied email claim rather than the OpenID Connect iss/sub identifier pair that OIDC Core §5.7 specifies as the only stable, unique identifier. Specifically, the upsert action (upsert_identity) and the sign-in preparation step (AshAuthentication.Strategy.OAuth2.SignInPreparation.prepare/3) both keyed off email without verifying the returned identity against a prior iss/sub binding.

Per the advisory, this is exploitable by an attacker who can register an account on any accepted OAuth/OIDC provider using the victim's email address — either because that provider doesn't strictly verify email ownership, or because the victim's email later becomes available for reclamation on that provider. Logging in via that provider then resolves to and authenticates as the victim's existing local account, with no misconfiguration required on the application side beyond enabling the affected strategies.

Why it matters for defenders

The advisory characterizes this as unauthenticated remote account takeover, granting the attacker the victim's full local privileges — read, write, and destructive access to whatever that account can do. Any application using AshAuthentication with an OAuth2/OIDC strategy in its default configuration is described as exposed, and risk increases with the number of accepted providers, since only the weakest-verifying provider in the set needs to be abusable.

What to watch for / do now

• Identify any applications in your environment built on AshAuthentication (Elixir/Phoenix ecosystem) and check whether OAuth2 or OIDC strategies are enabled.
• Apply the vendor's patch commits referenced in the advisory (separate backports for the 4.x and 5.x lines) as soon as feasible.
• Review which OAuth/OIDC providers are configured as accepted sign-in methods, and disable or restrict any that do not enforce verified, non-reusable email ownership.
• For log/audit hunting, look for sign-ins where the authenticating provider or iss/sub pair differs from what has historically been associated with a given account's email — this pattern is consistent with the takeover technique described.
• Consider this alongside broader OIDC integration reviews: any custom identity-matching logic that trusts email over iss/sub carries the same class of risk, independent of this specific library.

This is a same-day, developing disclosure — details may evolve as the community and downstream users assess exposure. For full technical detail, PoC steps, and patch commit references, see the original advisory: GHSA-777c-2fxx-qr28.