Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-41574

CVE-2026-41574: Nhost Auth Bypass Vulnerability

CVE-2026-41574 is an authentication bypass vulnerability in Nhost/auth that allows attackers to hijack accounts through OAuth identity linking. This post covers the technical details, affected versions, and mitigation steps.

Published:

CVE-2026-41574 Overview

CVE-2026-41574 is an authentication bypass vulnerability in Nhost, an open source Firebase alternative with GraphQL support. The flaw exists in versions prior to 0.49.1 of the nhost/auth service. Nhost automatically links an incoming OAuth identity to an existing account when email addresses match, which is only safe when the email has been verified by the OAuth provider. Several provider adapters fail to correctly populate the profile.EmailVerified boolean. An attacker can present an unowned email to Nhost, have the OAuth identity merged into a victim's account, and receive a full authenticated session [CWE-287].

Critical Impact

Attackers can fully take over Nhost user accounts by abusing OAuth identity linking through Discord, Bitbucket, AzureAD, and EntraID provider adapters.

Affected Products

  • Nhost nhost/auth versions prior to 0.49.1
  • Deployments using Discord and Bitbucket OAuth provider adapters
  • Deployments using Microsoft AzureAD and EntraID provider adapters

Discovery Timeline

  • 2026-05-08 - CVE-2026-41574 published to NVD
  • 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-41574

Vulnerability Analysis

The vulnerability resides in Nhost's OAuth2 controller logic, which trusts the profile.EmailVerified boolean returned by each provider adapter. When an OAuth callback presents an email that matches an existing Nhost account, the controller automatically links the new OAuth identity to that account and issues an authenticated session. This shortcut relies entirely on the adapter reporting an accurate verification state.

Multiple provider adapters break this assumption. The Discord adapter silently drops the verified field returned by the Discord API. The Bitbucket adapter falls back to accepting unconfirmed emails and marks them as verified. The Microsoft AzureAD and EntraID adapters derive the email from non-ownership-proving fields such as the user principal name, then mark it verified. An attacker controlling any of these identity sources can obtain a session for an arbitrary victim account.

Root Cause

The root cause is inconsistent handling of email verification state across OAuth provider adapters combined with implicit trust by the linking logic. The controller treats EmailVerified == true as proof of ownership without cross-checking the provider's actual claim semantics. There is no distinct "unknown" verification state, so adapters that lack a verified signal default to true rather than rejecting the link.

Attack Vector

An unauthenticated remote attacker registers or controls an account on a vulnerable OAuth provider, sets the profile email to the target victim's address, and initiates the OAuth login flow against the Nhost instance. Nhost matches the email to the victim's account and links the attacker's OAuth identity, returning an authenticated session that grants full access to the victim's data.

go
// Patch excerpt from services/auth/go/oidc/google.go
emailVerifiedStatus := EmailVerificationStatusUnknown

emailVerified, err := GetClaim[bool](token, "email_verified")
if err != nil && !errors.Is(err, ErrClaimNotFound) {
    return Profile{}, fmt.Errorf("failed to get email_verified claim from token: %w", err)
}

if err == nil {
    emailVerifiedStatus = EmailVerificationFromBool(emailVerified)
}

Source: GitHub Commit ec8dab3. The patch introduces an explicit EmailVerificationStatusUnknown state so adapters can no longer implicitly mark unverified emails as verified.

Detection Methods for CVE-2026-41574

Indicators of Compromise

  • New OAuth identity rows in the Nhost auth.user_providers table linked to existing accounts, particularly for Discord, Bitbucket, AzureAD, or EntraID providers.
  • Successful authentication sessions immediately following first-time OAuth linkage from an IP address or device fingerprint that has not previously accessed the account.
  • Account activity originating from regions or ASNs inconsistent with the legitimate user's history shortly after OAuth provider linkage events.

Detection Strategies

  • Audit OAuth identity linking events in Nhost auth logs and correlate the email claim with the provider's verified status field where available.
  • Flag any OAuth login where the Nhost version is below 0.49.1 and the provider is Discord, Bitbucket, AzureAD, or EntraID.
  • Compare the linked OAuth subject identifier against historical identifiers for the same account; first-time linkage of a new subject to an established account warrants review.

Monitoring Recommendations

  • Forward Nhost auth service logs to a centralized analytics platform and alert on OAuth identity merges into pre-existing accounts.
  • Monitor for spikes in OAuth login failures or sudden surges in successful logins from the four affected provider types.
  • Review session issuance metrics for anomalies tied to the /signin/provider/*/callback endpoints.

How to Mitigate CVE-2026-41574

Immediate Actions Required

  • Upgrade nhost/auth to version 0.49.1 or later, which enforces strict email verification handling across all OAuth provider adapters.
  • Invalidate all active sessions and force re-authentication after upgrade to evict any attacker sessions established via the flaw.
  • Audit recent OAuth identity link events and unlink any provider identity that cannot be confirmed by the legitimate account owner.

Patch Information

Nhost addressed CVE-2026-41574 in auth release v0.49.1 via Pull Request #4162 and commit ec8dab3. See the GHSA-6g38-8j4p-j3pr security advisory for full vendor guidance.

Workarounds

  • Disable the Discord, Bitbucket, AzureAD, and EntraID OAuth providers in Nhost auth configuration until the upgrade is applied.
  • Require an additional verification step, such as email confirmation or multi-factor authentication, before granting access through OAuth identity linkage.
  • Restrict OAuth sign-in to providers that reliably populate the verified email claim, such as Google with email_verified, while the patched version is rolled out.
bash
# Example: pin the patched auth service version in docker-compose.yaml
services:
  auth:
    image: nhost/hasura-auth:0.49.1
    environment:
      AUTH_PROVIDER_DISCORD_ENABLED: "false"
      AUTH_PROVIDER_BITBUCKET_ENABLED: "false"
      AUTH_PROVIDER_AZUREAD_ENABLED: "false"

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.