Which versions of AshAuthentication are affected by CVE-2026-49757?

AshAuthentication, a widely-used authentication library in versions prior to 4.14.0 and 5.0.0-rc.10, allows unauthenticated attackers to take over any user account by exploiting improper email…. A patch is available.

Is there a public PoC exploit available for CVE-2026-49757?

Yes, a public proof-of-concept exploit is available for CVE-2026-49757. Prioritise patching immediately. EPSS: 0.4%.

How to fix or mitigate CVE-2026-49757?

Within 24 hours: Identify all applications and systems using AshAuthentication library versions 0.1.0 to 4.13.x or 5.0.0-rc.0 to 5.0.0-rc.9; prioritize production systems. Within 7 days: Upgrade all affected applications to AshAuthentication version 4.14.0 (stable) or 5.0.0-rc.10 (release candidate) and deploy to production. Within 30 days: Review OAuth/OIDC provider configurations to ensure email_verified claims are properly validated and implement monitoring for suspicious account access patterns.

AshAuthentication CVE-2026-49757

Q: What is the CVSS score of CVE-2026-49757?

CVE-2026-49757 has a CVSS 4.0 base score of 9.2 (Critical). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

EUVD-2026-36714 CRITICAL

Authentication Bypass by Spoofing (CWE-290)

2026-06-15 EEF

GHSA-777c-2fxx-qr28

Authentication Bypass Ash Authentication Alembic

9.2

CVSS 4.0 · Vendor: EEF

Severity by source

Vendor (EEF) PRIMARY

9.2 CRITICAL

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.1 HIGH

Network-reachable and unauthenticated (AV:N/PR:N/UI:N) but requires a vulnerable OAuth strategy plus a provider that lets the attacker assert the victim's email, so AC:H; full account takeover yields C:H/I:H/A:H.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (EEF).

CVSS VectorVendor: EEF

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jun 15, 2026 - 12:20 vuln.today

Analysis Generated

Jun 15, 2026 - 12:20 vuln.today

DescriptionCVE.org

Authentication Bypass by Spoofing vulnerability in team-alembic AshAuthentication allows account takeover of local users via OAuth2/OIDC sign-in.

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address (an upsert on the email field, or a user-defined sign-in filter) rather than by the OpenID Connect iss/sub claim combination. Per OpenID Connect Core §5.7, only iss/sub uniquely and stably identifies an end-user; other claims, including email, MUST NOT be used as unique identifiers.

A provider login presenting a victim's email, including an unverified email, a reused email, or an account with email_verified: false, 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 (or who benefits from provider-side email reuse or reclamation) obtains the victim's full local privileges.

The fix resolves users by the (strategy, sub) identity stored in a user identity resource, and only links a new sub to an existing local account by email when the provider's email_verified claim is trusted (trust_email_verified?).

This issue affects ash_authentication from 0.1.0 before 4.14.0 and from 5.0.0-rc.0 before 5.0.0-rc.10.

AnalysisAI

Account takeover in team-alembic AshAuthentication (0.1.0 to <4.14.0 and 5.0.0-rc.0 to <5.0.0-rc.10) lets an unauthenticated attacker hijack any local user account by completing an OAuth2 or OIDC sign-in with the victim's email address. The library matched federated logins to local users by email rather than by the OpenID Connect iss/sub pair, so any accepted provider that allows an attacker to register or reuse the victim's email - including providers that return email_verified: false - resolves to the victim's existing account. No public exploit identified at time of analysis, but the underlying technique (OIDC email-claim takeover) is well-documented and trivially reproducible.

Technical ContextAI

AshAuthentication is an authentication library for the Elixir Ash Framework, providing OAuth2/OIDC strategies (Auth0, Apple, generic OAuth2, OIDC) that federate sign-in to a local user resource. The root cause is CWE-290 (Authentication Bypass by Spoofing): the OAuth2/OIDC strategies performed the user upsert against the email claim (or a user-defined sign-in filter), which violates OpenID Connect Core §5.7 - only the (iss, sub) tuple is defined as a stable, unique end-user identifier; email is mutable, reusable, and may be unverified. The patched code introduces a mandatory identity_resource that persists (strategy, sub) per user and gates email-based linking behind a per-strategy trust_email_verified? flag plus an on_untrusted_email_match policy (:reject by default, or :confirm via an email round-trip).

RemediationAI

Vendor-released patch: upgrade ash_authentication to 4.14.0 on the 4.x line or 5.0.0-rc.10 on the 5.x pre-release line (commits 728b8d28c1b5f465fa1116ef044a815300fc733d and 64530644f9b37ebb76ca14aeb83a77597a0034b7). After upgrading, every OAuth2/OIDC strategy now requires an identity_resource so that (iss, sub) is persisted; configure one per the migrated DSL docs at https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-777c-2fxx-qr28. Review the new trust_email_verified? flag for each provider and leave it false for any provider that does not strictly enforce email ownership (the default on_untrusted_email_match is :reject, which is the safe choice); enabling :confirm requires the confirmation add-on and a carefully worded link-confirmation email, since a misleading message lets an attacker trick a legitimate user into linking the attacker's provider identity. If immediate upgrade is impossible, the only meaningful workaround is to disable all OAuth2/OIDC strategies and restrict authentication to password or magic-link, accepting the loss of SSO; restricting accepted providers to ones that always set email_verified: true and never permit email reuse (e.g., Google Workspace tenants you control) reduces but does not eliminate exposure because the underlying email-based match is still wrong.