Skip to content

CVE-2026-41574 - Nhost OAuth email verification bypass

Nhost could link a new OAuth identity to an existing account when email addresses matched even when the provider email was not reliably verified. The advisory identifies provider adapters that either ignored a verification field, accepted an unconfirmed fallback email, or treated non-ownership-proving Microsoft identity fields as verified email.

The result is account takeover: an attacker can authenticate with a provider identity that presents the victim’s email address, have that provider identity linked to the victim’s Nhost account, and receive a valid session for the victim account.

Affected versions

  • Vulnerable: github.com/nhost/nhost <0.0.0-20260417112436-ec8dab3f2cf4
  • Fixed: github.com/nhost/nhost 0.0.0-20260417112436-ec8dab3f2cf4+
  • Affected providers called out by the advisory: Discord, Bitbucket, AzureAD, and EntraID.
  • Affected behavior: provider identity linking by matching email without a trustworthy provider-level verified-email guarantee.

Indicator-of-exposure

  • The repository builds, vendors, deploys, or configures Nhost Auth from a vulnerable revision.
  • OAuth/OIDC login is enabled for Discord, Bitbucket, AzureAD, EntraID, or a custom provider that maps EmailVerified from weak assumptions.
  • Existing account lookup or provider linking depends on email equality.
  • Provider adapters set EmailVerified from email != "", fallback username fields, user principal names, unconfirmed email lists, or missing verification fields.
  • Applications grant admin, workspace, billing, tenant, agent, MCP connector, or production privileges through Nhost sessions.

Quick checks:

rg -n "github.com/nhost/nhost|nhost|providerFlowSignIn|InsertUserProvider|EmailVerified|email_verified|verified|is_confirmed|discord|bitbucket|azuread|entraid|oauth|oidc" .
go list -m all | rg 'github.com/nhost/nhost'
rg -n "AUTH|OAUTH|OIDC|DISCORD|BITBUCKET|AZURE|ENTRA|NHOST" .env* Dockerfile* docker-compose*.yml charts deploy k8s helm .github .

Remediation strategy

  • Upgrade Nhost to 0.0.0-20260417112436-ec8dab3f2cf4+ everywhere this repository controls source, images, deployment manifests, SBOMs, or docs.
  • Require provider-specific verified-email evidence before automatic account linking by email.
  • Remove adapter patterns that mark email as verified merely because it is present.
  • Disable or gate vulnerable providers until the fixed Auth service is rolled out.
  • Add regression tests proving unverified Discord and Bitbucket emails do not link to existing accounts, and Microsoft fallback identity fields cannot be used as email-ownership proof.
  • Audit provider links created during the vulnerable window and expire sessions for suspicious or affected accounts.

The prompt 

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-41574 / GHSA-6g38-8j4p-j3pr (Nhost OAuth email
verification bypass leading to account takeover). Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Nhost or fixes the OAuth
  account-linking guard, adds regression coverage, and documents operator
  actions, or
- TRIAGE.md if this repository does not own an affected Nhost Auth deployment
  or cannot make a safe change.

## Rules

- Scope only CVE-2026-41574 / GHSA-6g38-8j4p-j3pr.
- Treat OAuth tokens, ID tokens, refresh tokens, cookies, session IDs, user
  profile payloads, provider IDs, emails, audit logs, and linked-account data as
  sensitive.
- Do not create test accounts using real victim emails or real production
  identity providers.
- Do not silently unlink, merge, delete, or relink user identities.
- Do not log token material or full provider payloads.
- Do not auto-merge.

## Steps

1. Inventory every Nhost Auth asset controlled by this repository:
   Go modules, vendor trees, generated clients, Dockerfiles, compose files,
   Helm/Kubernetes manifests, Terraform, CI images, SBOMs, runbooks,
   environment templates, auth configuration, and deployment docs.
2. Determine whether `github.com/nhost/nhost` resolves below
   `0.0.0-20260417112436-ec8dab3f2cf4`.
3. Identify enabled OAuth/OIDC providers, especially Discord, Bitbucket,
   AzureAD, and EntraID. Include local, staging, production, preview, and
   self-hosted configurations.
4. Search account-linking code and provider adapters for `EmailVerified`,
   `email_verified`, `verified`, `is_confirmed`, `InsertUserProvider`,
   `providerFlowSignIn`, fallback email logic, `preferred_username`, user
   principal name, and `email != ""` verification shortcuts.
5. If this repository does not own an affected Nhost Auth deployment, stop with
   `TRIAGE.md` listing files checked, resolved versions, enabled providers if
   visible, suspected runtime owner, and the exact upgrade requested.
6. Prefer upgrading to `github.com/nhost/nhost`
   `0.0.0-20260417112436-ec8dab3f2cf4+`. Regenerate `go.sum`, vendor metadata,
   SBOMs, images, and rendered deployment manifests.
7. If this repository owns a fork or equivalent auth code, patch the invariant:
   - never auto-link an incoming provider identity to an existing account unless
     the provider email is explicitly verified by that provider;
   - reject Discord emails when the provider `verified` value is false or
     absent;
   - reject Bitbucket emails unless they come from a confirmed email record;
   - do not use AzureAD or EntraID `preferred_username`, UPN, or equivalent
     tenant-local identifiers as verified external email ownership proof;
   - fail closed for provider adapters that cannot prove email verification.
8. Add regression tests:
   - unverified Discord email does not link to an existing account;
   - Bitbucket unconfirmed fallback email does not link;
   - AzureAD/EntraID fallback identifiers do not link as verified email;
   - verified provider email still links only when provider ID and tenant
     constraints are valid;
   - a custom/new provider with missing verification data fails closed.
9. Add temporary containment if upgrade cannot be deployed immediately:
   - disable affected OAuth providers;
   - block automatic provider linking by email;
   - require existing-session reauthentication for privileged users;
   - increase audit logging without recording secrets.
10. Add a PR body section named `CVE-2026-41574 operator actions` that states:
    - affected Nhost version before and after;
    - enabled OAuth/OIDC providers;
    - whether automatic provider linking by email was enabled;
    - which sessions, cookies, refresh tokens, or auth caches must be expired;
    - how to audit provider links created during the vulnerable window;
    - which suspicious linked identities require human-reviewed unlinking or
      account recovery.
11. Run relevant validation: auth unit tests, provider adapter tests,
    integration tests with mocked provider payloads, `go test ./...`,
    dependency/security scan, SBOM refresh, image build, and deployment render.
12. Use PR title:
    `fix(sec): enforce verified OAuth email linking in Nhost`

## Stop conditions

- No affected Nhost Auth deployment is controlled by this repository.
- A fixed Nhost revision cannot be consumed without a broader auth migration.
- Provider-link cleanup requires changing real user ownership without an
  operator-approved recovery plan.
- Verification would require real provider accounts, production emails, or
  production tokens.
- Tests fail for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled module, vendor tree, SBOM, image, or deployment target resolves github.com/nhost/nhost below 0.0.0-20260417112436-ec8dab3f2cf4.
  • Automatic account linking requires provider-backed verified email evidence.
  • Discord, Bitbucket, AzureAD, EntraID, and missing-verification regression tests fail closed.
  • Operator actions cover session expiry, provider-link auditing, and human-reviewed account recovery.
  • The change does not log OAuth secrets or silently mutate linked identities.

Watch for

  • Fixing one provider adapter while leaving the controller-level linking path willing to trust future weak providers.
  • Treating preferred_username, UPN, or any tenant-local identifier as proof that a user controls an external email address.
  • Keeping long-lived sessions that were minted after a suspicious provider link.
  • Updating source but leaving old Nhost Auth images or Helm values deployed.
  • Tests that only cover successful verified login and never assert unverified email rejection.

References