SURIQ
Email is something you have, not proof of who you are. A login flaw made public on June 15, 2026 is a clean demonstration of what happens when code forgets that. CVE-2026-49757 is a critical account-takeover bug, rated 9.2 out of 10, in ash_authentication, the authentication library used by Elixir applications built on the Ash Framework. A working proof-of-concept appeared on GitHub the same week. If you run an affected version, the right reaction is to patch first and read the analysis second.
The short version: the library decided who you were by your email address. An attacker who could get a victim's email onto any login provider the application accepted would sign in as that victim, with full access to their account. An unverified email worked. A reused or reclaimed email worked. That is about as bad as a sign-in bug gets.
What actually goes wrong at login
When you click 'log in with Google' or any similar button, the provider hands the application a bundle of facts about you. One of those facts is your email. Another is a pair of values the standard calls the issuer and the subject, which together name exactly one person at exactly one provider and never change.
The vulnerable code reached for the wrong fact. Its OAuth2 and OpenID Connect sign-in matched the local user by email, through an upsert that resolved on the email field, and a sign-in step that never checked the returned account against a stable identifier. So two different people who present the same email string look like the same account.
That turns a sign-in into an impersonation primitive. An advisory from the maintainers spells out the impact in plain terms: an unauthenticated remote attacker who registers an account carrying the victim's email, on any provider the app trusts, lands inside the victim's existing local account and inherits its read, write, and delete rights. No password, no phishing, no malware.
Why matching on email is the real bug
This is not an Elixir problem or an Ash problem. It is a federated-login problem that any team can write into any language. The pattern looks innocent: a provider returns an email, you find-or-create a user by that email, you log them in. It reads like good hygiene. It is a hole.
OpenID Connect is explicit about this. Section 5.7 of the core specification says the issuer and subject pair is the only thing that stably and uniquely identifies an end user, and that other claims, email included, must not be treated as unique identifiers. Email fails as a key for reasons that have nothing to do with any one provider: addresses get reassigned when an employee leaves, free providers let anyone pick almost any local part, and an attacker only needs one accepted provider that does not verify the address before issuing a token.
Accepting several providers makes that worse, not better. Each provider you trust is another place an attacker can shop for a way to assert the email they want. The weakest one sets your security. We saw a cousin of this thinking in the CoreWCF signature bypass, where the question was whether a trusted assertion was really trustworthy, and in the Salesforce connected-app abuse, where an over-trusted OAuth grant was the way in. Identity systems break at the joints where one system decides to believe another.
Am I affected?
You are exposed if your application uses ash_authentication with an OAuth2 or OpenID Connect strategy on any version from 0.1.0 up to but not including 4.14.0, or on a release candidate from 5.0.0-rc.0 up to but not including 5.0.0-rc.10. The flaw is tracked as CVE-2026-49757 and classified as authentication bypass by spoofing.
Two conditions shape real-world risk, and they are low bars rather than real obstacles. The target needs an existing local account, and the attacker needs an accepted provider on which they can stand up that account's email. For most consumer-facing apps that accept a mainstream social login, both are trivially met. There is no confirmed exploitation in the wild as of June 21, 2026, but a public proof-of-concept exists, so assume capable attackers can reproduce it.
What to do right now
Upgrade ash_authentication to 4.14.0, or to 5.0.0-rc.10 if you track the 5.0 release candidates. The fix changes the matching logic at the root: it resolves users by the provider's subject identity, stored as a separate user-identity record, and will tie a fresh subject to a pre-existing account through email only where the provider vouches for that address with a trusted email_verified claim. That is the correct minimal pattern, and it is worth copying into any sign-in code you own, not just this library.
After you patch, do not stop at the version bump. Audit existing account links. Look for any local account associated with more than one provider subject, and for identity links that could only have been created through email matching. Those are the records an attacker would have used while the door was open. Pull authentication logs and check for sign-ins to established accounts that arrive from a provider or subject the account has never used before. A predictable or attacker-influenced recovery path makes this kind of takeover stickier once it happens, a lesson from the JetBrains Hub recovery-code weakness, so rotate sessions and force re-authentication on anything that looks off.
The pattern worth remembering
Every few months a real product ships the same mistake: treating an email address as a name tag that proves identity. It is convenient, it usually works in testing, and it quietly turns sign-in into a guessing game an attacker can win. The account-takeover bugs we keep covering rarely involve clever cryptography. They involve a system trusting the wrong field.
If your team builds or maintains any sign-in flow that accepts an outside identity provider, treat this as a prompt to go read your own matching code today. Find the line that decides which existing user a fresh login belongs to. If that line looks at email, you have homework before the next person finds it for you.