CVE-2026-41574 is a critical authentication flaw (CVSS 9.8) in the Nhost auth service. Before version 0.49.1, an OAuth login with an unverified email can be merged into an existing account with the same address. That gives an attacker a full session. Upgrade the auth service to 0.49.1.
What's affected
The GitHub advisory lists the Nhost auth service before 0.49.1, and 0.49.1 as the patched version. The advisory says several OAuth provider adapters do not set the email verified flag correctly:
- Discord: the adapter drops a verified field that the provider API does return.
- Bitbucket: it falls back to unconfirmed emails and marks them verified.
- AzureAD and EntraID: the email comes from fields such as the user principal name, which does not prove ownership, and is then marked verified.
Providers whose adapters set the flag correctly, such as GitHub per the advisory, are not part of the list.
How to check if you're exposed
Find the version of the auth service in your Nhost deployment, whether you self host the container or use a managed project, and compare it with 0.49.1. Then list which OAuth providers your project has enabled. The exposure is highest if Discord, Bitbucket, AzureAD or EntraID sign in is on.
Check your user and provider link tables for provider identities attached to accounts in unexpected ways, such as a new link on an account that the owner did not touch.
What to do now
- Upgrade the Nhost auth service to 0.49.1 or later.
- Until you can, disable sign in with the affected providers.
- Review linked OAuth identities on important accounts, especially admin users, and unlink ones you do not recognise.
- Invalidate active sessions for accounts you suspect and ask those users to sign in again.
- Add a check that account linking only happens for provider emails that are truly verified.
Why it matters
The record lists CWE-287, improper authentication. The advisory shows the linking step trusted a boolean from each adapter without a second check. When an adapter sets it wrongly, the controller treats an unproven email as owned by the person signing in.
This is a known account takeover pattern in federated login: email is not an identity unless the provider proves control of it. The fix is for the controller to be strict, and for each adapter to map the provider's real verification data. The record does not flag this CVE as known exploited.
Quick check
We only use GitHub sign in. Do we need this?
The advisory describes GitHub as correctly mapped. Upgrade anyway, since the fix is the same release.
Sources
Last reviewed: 19 October 2026.
