CVE-2026-49757: Ash authentication AshAuthentication Vulnerable To OAuth2/OIDC Account Vulnerability

CRITICAL
Advisory Identifier: GHSA-777c-2fxx-qr28
CWE-290
Published
Advisory Summary

CVE-2026-49757 is a CRITICAL ashauthentication vulnerable to oauth2/oidc account vulnerability (CWE-290: Authentication Bypass by Spoofing) affecting Ash authentication libraries in the Hex ecosystem. The issue involves ashauthentication vulnerable to oauth2/oidc account takeover via email-based user matching. Remediation is available by upgrading affected packages to version 4.14.0, 5.0.0-rc.10.

CVE-2026-49757 at a Glance

CVE Identifier CVE-2026-49757
GHSA Identifier GHSA-777c-2fxx-qr28
Severity CRITICAL
CVSS v3.1 Base Score N/A
CWE Classification CWE-290: Authentication Bypass by Spoofing
Affected Product Ash authentication
Package Ecosystem Hex
Published Date
Last Updated

How to Fix CVE-2026-49757

To remediate this vulnerability, upgrade all affected Ash authentication dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

ash_authentication fixed: 4.14.0
Upgrade ash_authentication to 4.14.0
ash_authentication fixed: 5.0.0-rc.10
Upgrade ash_authentication to 5.0.0-rc.10
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for ash_authentication

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-49757, inspect your project dependencies for Ash authentication:

inspect dependencies for ash_authentication

Analyze the terminal output to locate any version of Ash authentication in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 4.14.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-290: Authentication Bypass by Spoofing, where this attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. In Ash authentication, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary 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 1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse). 2. Complete the standard OAuth flow against the AshAuthentication application. 3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account. ### 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. ## 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

CVE-2026-49757 Affected Ash authentication Versions

2 component(s)
Fixed Versions:
4.14.05.0.0-rc.10
Product / Package Ecosystem Affected Versions Fixed Version
ash_authentication
Hex
≥ 0.1.0
< 4.14.0
4.14.0
ash_authentication
Hex
≥ 5.0.0-rc.0
< 5.0.0-rc.10
5.0.0-rc.10

References

Frequently Asked Questions

What is CVE-2026-49757?
CVE-2026-49757 is a security vulnerability in Ash authentication involving AshAuthentication vulnerable to OAuth2/OIDC account takeover via email-based user matching under CWE-290: Authentication Bypass by Spoofing.
Which Ash authentication versions are affected?
Affected versions include releases prior to 4.14.0, 5.0.0-rc.10 across affected packages: ash_authentication.
What version fixes CVE-2026-49757?
Upgrading to 4.14.0, 5.0.0-rc.10 (or the latest patched release for your respective branch) resolves the vulnerability.
Is ash_authentication affected?
Yes, ash_authentication is affected in releases prior to 4.14.0, 5.0.0-rc.10. Upgrade your dependency to 4.14.0, 5.0.0-rc.10 or later.
What CWE is associated with CVE-2026-49757?
CVE-2026-49757 is classified under CWE-290: Authentication Bypass by Spoofing (This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.).
How can I check Hex dependencies for CVE-2026-49757?
Run the dependency tree command: 'inspect dependencies for ash_authentication'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-777c-2fxx-qr28",
  "modified" : "2026-08-25T18:20:27Z",
  "published" : "2026-08-25T18:20:27Z",
  "aliases" : [ "CVE-2026-49757" ],
  "summary" : "AshAuthentication vulnerable to OAuth2/OIDC account takeover via email-based user matching",
  "details" : "### Summary\n\nAshAuthentication'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.\n\n### Details\n\nPer 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.\n\n**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.\n\n**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.\n\n**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.\n\n#### Configurations\n\nExploitation requires one of:\n\n* 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.\n* 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.\n\nProviders 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.\n\n### PoC\n\n1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).\n2. Complete the standard OAuth flow against the AshAuthentication application.\n3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.\n\n### Impact\n\nUnauthenticated 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.\n\n## References\n\n* Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2\n* Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d\n* Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Hex",
      "name" : "ash_authentication"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.1.0"
      }, {
        "fixed" : "4.14.0"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "Hex",
      "name" : "ash_authentication"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "5.0.0-rc.0"
      }, {
        "fixed" : "5.0.0-rc.10"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-777c-2fxx-qr28"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-49757"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d"
  }, {
    "type" : "WEB",
    "url" : "https://cna.erlef.org/cves/CVE-2026-49757.html"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/team-alembic/ash_authentication"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/team-alembic/ash_authentication/releases/tag/v4.14.0"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/team-alembic/ash_authentication/releases/tag/v5.0.0-rc.10"
  }, {
    "type" : "WEB",
    "url" : "https://osv.dev/vulnerability/EEF-CVE-2026-49757"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-290" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-25T18:20:27Z",
    "nvd_published_at" : "2026-06-15T12:16:25Z"
  }
}