CVE-2026-49757: AshAuthentication Auth Bypass Vulnerability

CVE-2026-49757 Overview

CVE-2026-49757 is an authentication bypass by spoofing vulnerability in team-alembic AshAuthentication, an authentication framework for the Ash ecosystem in Elixir. The flaw allows account takeover of local users through OAuth2 and OpenID Connect (OIDC) sign-in flows. AshAuthentication matched provider users to local accounts by email address rather than by the OpenID Connect iss/sub claim combination. An unauthenticated attacker who controls an OAuth provider account using the victim's email can sign in as the victim with full local privileges. The 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.

Critical Impact
Unauthenticated attackers can take over arbitrary local user accounts by registering an OAuth/OIDC provider account with the victim's email address, obtaining full local privileges without any user interaction.

Affected Products

team-alembic ash_authentication0.1.0 through versions before 4.14.0
team-alembic ash_authentication5.0.0-rc.0 through versions before 5.0.0-rc.10
Elixir/Ash applications using OAuth2 or OIDC family strategies in AshAuthentication

Discovery Timeline

2026-06-15 - CVE-2026-49757 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-49757

Vulnerability Analysis

The vulnerability resides in how AshAuthentication's OAuth2 and OIDC family strategies resolve a provider login to a local user. The library performed an upsert (or applied a user-defined sign-in filter) keyed on the email field returned from the identity provider. Per OpenID Connect Core §5.7, only the combination of iss (issuer) and sub (subject) uniquely and stably identifies an end-user. Other claims, including email, must not be used as unique identifiers. By treating email as the linking key, the framework allowed a provider-supplied email to determine which local account a sign-in resolved to. This is classified as [CWE-290] Authentication Bypass by Spoofing.

Root Cause

The root cause is the use of a non-stable, user-controllable claim (email) as the unique user identifier across the OAuth2/OIDC sign-in flow. The framework did not require an identity_resource to store the (strategy, sub) tuple, and it did not gate email-based linking on the email_verified claim. As a result, an account presenting an unverified email, a reused email, or an email reclaimed at the provider could resolve to the victim's existing local account.

Attack Vector

An unauthenticated attacker registers an account on any OAuth provider accepted by the target application using the victim's email address. Where the provider does not verify the email, or where the provider permits email reuse or reclamation, the attacker proceeds through the standard OAuth2/OIDC sign-in flow. The application receives provider claims, matches the local user by email, and issues a session bound to the victim's account. The attacker inherits the victim's full local privileges.

text

# Patch excerpt: lib/ash_authentication/add_ons/confirmation/actions.ex
# fix!: require an `identity_resource` and resolve OAuth2/OIDC users by `iss`/`sub`

    TokenResource
  }

+  # Reserved `extra_data` key under which an OAuth2/OIDC identity link is stashed
+  # for `on_untrusted_email_match :confirm`. Namespaced so it cannot collide with
+  # a monitored field name.
+  @oauth_identity_key "__oauth_identity__"
+
  @doc """
  Attempt to confirm a user.
  """

Source: GitHub Commit 64530644

Detection Methods for CVE-2026-49757

Indicators of Compromise

Successful OAuth2/OIDC sign-in events for accounts where the provider claim email_verified is false or absent.
Sign-in events where the provider sub claim for a given local account changes between sessions.
Multiple distinct provider iss/sub pairs resolving to the same local user record within a short window.
Account activity from new IP addresses or user agents immediately following an OAuth/OIDC sign-in.

Detection Strategies

Audit authentication logs for OAuth2/OIDC sign-ins lacking a verified email_verified: true claim.
Correlate iss/sub claims with local account identifiers and alert on mismatches or new pairings for existing accounts.
Review ash_authentication dependency versions across deployments to identify hosts running affected releases.

Monitoring Recommendations

Ingest OAuth provider sign-in logs alongside application authentication logs for cross-source correlation.
Track high-privilege account access patterns and alert on sign-ins immediately following changes to linked identities.
Monitor provider-side email reclamation events for tenants where this is permitted.

How to Mitigate CVE-2026-49757

Immediate Actions Required

Upgrade ash_authentication to 4.14.0 or later on the 4.x line, or to 5.0.0-rc.10 or later on the 5.x release-candidate line.
Configure an identity_resource so OAuth2/OIDC users are resolved by the stored (strategy, sub) identity.
Set trust_email_verified? only for providers known to enforce email verification, and require email_verified: true before linking a new sub to an existing local account by email.
Invalidate active sessions established via OAuth2/OIDC sign-in prior to patching and require re-authentication.

Patch Information

The maintainers shipped fixes in commits 64530644 and 728b8d28. The patches require an identity_resource for all OAuth2 and OIDC strategies and resolve users by the iss/sub identity. Linking a new sub to an existing local account by email is permitted only when the provider's email_verified claim is trusted. Details are available in the GitHub Security Advisory GHSA-777c-2fxx-qr28 and the Erlef CVE-2026-49757 advisory.

Workarounds

Disable OAuth2 and OIDC sign-in strategies until the upgrade and identity resource configuration are in place.
Restrict accepted OAuth providers to those that enforce email verification and do not permit email reuse or reclamation.
Add a provider-side check that rejects sign-ins where email_verified is not true for any flow that links to a pre-existing local user.

bash

# Update dependency in mix.exs to a fixed release, then fetch and compile
# 4.x line
{:ash_authentication, "~> 4.14.0"}

# 5.x release-candidate line
{:ash_authentication, "~> 5.0.0-rc.10"}

mix deps.update ash_authentication
mix deps.compile ash_authentication --force