Listen to this Post
AshAuthentication is an authentication framework for Elixir/Ash applications. Its OAuth2 and OpenID Connect (OIDC) family strategies contained a critical vulnerability (CVE-2026-49757) that allowed unauthenticated attackers to take over any local user account.
Per OpenID Connect Core §5.7, only the `iss` (issuer identifier) and `sub` (subject identifier) 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 violated this fundamental security principle. The `IdentityChange.change/3` function invoked an upsert action that resolved users by the email field (upsert_identity on email or a user-defined sign-in filter). The `SignInPreparation.prepare/3` function then filtered users by email without verifying the returned user against an `iss/sub` identity.
The attack unfolds in three steps:
Step 1 – Provider Login: The attacker signs in to a configured OAuth/OIDC provider using the victim’s email address. This is trivial for providers that don’t verify email ownership and possible under email-reuse or reclamation scenarios for providers that do.
Step 2 – AshAuthentication Register: `Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange:change/3` invokes the upsert action, resolving on the email field and landing on the victim’s existing local record.
Step 3 – Sign-in Preparation: `Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation:prepare/3` does not verify the returned user against an `iss/sub` identity, authenticating the attacker as the victim.
Exploitation requires either a configured OAuth/OIDC provider that does not reliably verify email ownership (Slack, generic OIDC deployments, custom OAuth2 endpoints) or one that allows email reclamation (account deletion, organisation off-boarding, mail-host changes). Providers like Google Workspace and GitHub (with completed verification) are not directly exploitable, but applications accepting any affected strategy remain exposed via weaker providers.
The vulnerability affects `ash_authentication` from version 0.1.0 before 4.14.0 and from 5.0.0-rc.0 before 5.0.0-rc.10.
DailyCVE Form
Platform: Elixir/Ash (ash_authentication)
Version: <4.14.0, <5.0.0-rc.10
Vulnerability: Authentication Bypass by Spoofing
Severity: Critical (CVSS 4.0: 9.2)
Date: 2026-06-15
Prediction: 2026-06-15 (patches released)
What Undercode Say
Analytics & Detection Commands
Check your `mix.exs` for vulnerable versions:
grep -E "ash_authentication.[0-9]+.[0-9]+.[0-9]+" mix.exs
List all accepted OAuth/OIDC providers in your configuration:
grep -r "use AshAuthentication" lib/ --include=".ex" -A 20 | grep -E "oauth2|oidc|strategies"
Audit your `upsert_identity` configuration:
grep -r "upsert_identity" lib/ --include=".ex" -B 5 -A 5
Check for `email`-based user resolution:
grep -r "resolve.email|filter.email" lib/ --include=".ex" -B 3 -A 3
Exploit (Educational Purposes!)
PoC Flow:
- On any accepted OAuth/OIDC provider, register an account using the victim’s email address (or use a provider allowing 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.
- The application returns a session token for the victim’s account.
Simulated vulnerable handler (Python – educational use only) :Vulnerable: resolves by email def vulnerable_handler(provider_email, provider_sub): IdentityChange.change/3 - upsert by email user = db.upsert_user_by_email(provider_email) ❌ vulnerable SignInPreparation.prepare/3 - no iss/sub verification return create_session(user.id) ❌ attacker gets victim's session
Simulated fixed handler:
Fixed: resolves by (strategy, sub) def fixed_handler(strategy, provider_sub, provider_email, email_verified): identity = db.get_identity(strategy, provider_sub) ✅ correct lookup if identity: return create_session(identity.user_id) on_untrusted_email_match: :reject (default) return reject_login() ✅ attack prevented
Protection
The vulnerability is patched in ash_authentication 4.14.0 and 5.0.0-rc.10. Immediate actions:
1. Upgrade immediately to the patched versions.
- Verify the fix implementation – The patched `UserResolver` module resolves users by the `(strategy, sub)` identity stored in a user identity resource.
- Configure `on_untrusted_email_match` – Options: `:reject` (default, blocks unknown subs), `:confirm` (sends confirmation token to victim’s email), or
:warn. - Set `trust_email_verified?` – Per-provider flag; defaults `true` for trusted providers (GitHub, Google, Auth0, Slack, Apple). Only link a new `sub` to an existing local account by email when the provider’s `email_verified` claim is trusted.
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.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
