External risk intelligence

AshAuthentication Bypass Allows Account Takeover via OAuth2/OIDC

CVE advisorySeverity: CRITICAL (CVSS 9.2)

CVE-2026-49757

The vulnerability affects an authentication library used for OAuth2/OIDC sign-in mechanisms. These identity portals and authentication endpoints are designed to be public-facing to facilitate external user logins and are commonly deployed as internet-accessible services in modern web applications.

Authentication Bypass

Halo Surface Signal: 5 out of 5 — more likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This critical vulnerability in an authentication library could allow unauthorized account takeover for local users by spoofing their credentials through OAuth2 or OIDC sign-in. An attacker could potentially gain full local privileges by exploiting how the system matches users to external identity providers, bypassing standard security checks. The main concern is confirming relevance and exposure within our systems.

  • Allows attackers to take over user accounts.
  • Impacts login security via common external providers.
  • Confirm if this authentication method is used.

Attack Path

How an attacker could exploit the issue

An attacker can bypass authentication by impersonating a local user through OAuth2 or OIDC sign-in. This is possible because the system matches users by email address instead of the unique identifier required by OpenID Connect. An unauthenticated attacker who can register an account on a connected OAuth provider with a victim's email address can then gain full access to the victim's local account privileges.

  • Attacker registers an account on an OAuth provider with victim's email.
  • Attacker initiates OAuth2/OIDC sign-in using the compromised provider account.
  • Leads to account takeover of local users.

Live Threat

Current exploitation, exposure, and threat context

An attacker could gain unauthorized access to local user accounts by exploiting how the authentication system matches users via email addresses instead of the unique user identifier provided by OAuth2/OIDC. This bypasses standard authentication when an attacker can control an OAuth provider account associated with a victim's email address, potentially leading to account takeover.

  • Local user accounts could be compromised.
  • Attacker spoofs email during OAuth2/OIDC sign-in.
  • Full local account privileges may be obtained.

Operational Fix

Recommended remediation, mitigation, and detection steps

Application owners and platform teams are likely responsible for addressing this critical authentication bypass vulnerability. The first practical move is to identify all instances of the affected authentication library, confirm their reachability and business criticality, and then coordinate remediation with the accountable owner.

  • Ownership lies with application or platform teams.
  • Verify affected technology in production.
  • Plan remediation based on exposure.

Supplementary metadata

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Frequently asked questions

What is the ash_authentication library?

AshAuthentication is an Elixir-based framework designed to simplify adding user authentication, such as password-based login or third-party OAuth2 and OIDC sign-ins, to applications. It acts as a middleware or toolset that developers integrate into their projects to manage user sessions and identity verification, ensuring that users can securely sign into web services using external providers like Google or GitHub.

How does CVE-2026-49757 bypass authentication?

This vulnerability involves a weakness classified as Authentication Bypass by Spoofing (CWE-290). The software incorrectly relied on a user's email address to match accounts during sign-in. Because email addresses are not unique identifiers, an attacker can link their own account from a third-party service to an existing local user's account just by matching the email, effectively tricking the system into logging the attacker into the victim's account.

Do I need to be a known user to trigger this bug?

No. An attacker does not need prior access or a pre-existing account on your system to trigger this. They simply need the ability to register an account on an OAuth provider that you accept. The vulnerability is not triggered by legitimate, verified login flows where the provider's unique identifier is correctly validated, but rather by the flawed logic that defaults to matching users based solely on their email address.

Is my application at risk if it uses OAuth2 login?

If your application uses the affected ash_authentication library for external sign-ins, Halo Surface Signal indicates it is very likely at risk. Because these authentication endpoints are designed to accept traffic from external identity providers, they are typically internet-facing. This exposure makes it significantly easier for an unauthenticated attacker to reach the vulnerable login logic from anywhere on the internet.

What steps should I take if I use this library?

Begin by auditing your dependency manifests to confirm if you are running a version of ash_authentication between 0.1.0 and 4.13.x, or the 5.0.0-rc series before rc.10. Once confirmed, prioritize updating to a patched version that resolves identities using unique provider claims like 'sub' rather than just email. Work with your development team to ensure the new security logic for handling email verification is properly implemented in your sign-in workflows.

References