CVE-2026-120999: Improper authentication lets Google sign-in and confirmation links sign users in to accounts registered with their email address by someone else
Improper Authentication vulnerability in Google sign-in and email confirmation in nerves-hub nerveshubweb allows an attacker who registers another person's email address to share that person's account once they sign in. NervesHub.Accounts.updateorcreateuserfromueberauth/1 signs a Google user in to any account carrying the same email that is not yet linked to a Google account, links it and marks the email confirmed, without the account's owner ever having proved they own the address. NervesHubWeb.SessionController.confirm/2 likewise signs in whoever follows a confirmation link. An attacker registers the address from the sign-up form, changes their own account's email to it, or registers it as an organization admin from an invite link, and keeps the password; when the address's owner signs in with Google or follows the confirmation link, they land in that account.
The Google path also creates accounts with registrations closed and never checks Google's emailverified claim, and the API's password sign-in in NervesHubWeb.API.UserController issues tokens to accounts whose email was never confirmed. The attacker gains only what the victim is granted afterwards, and nothing on accounts whose owners never use either path.
This issue affects nerveshub: from 2.3.0 before 2.5.3.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
nerves_hubto a version that resolves this vulnerability.Fixed in 2.5.3 - Configuration
Set SIGN_UP_METHODS=google for instances that relied on Google sign-in to create accounts while registrations were disabled; this replaces OPEN_FOR_REGISTRATIONS.
nerves_hub SIGN_UP_METHODS = google - Operational
Review users rows containing both password_hash and google_id, comparing inserted_at with google_last_synced_at to identify accounts registered for another person's address before their first Google sign-in.
- Operational
For an account its owner did not set up, set google_id to NULL, delete its user_tokens rows to end sessions and revoke API tokens, and have the address owner reset the password.
Event History
Frequently Asked Questions
What does an attacker need to do before a victim can be affected?
The attacker must first create or control an account carrying the victim's email address, such as by registering it through the sign-up form, changing their own account email to that address, or registering it as an organization admin through an invite link. They retain the password while waiting for the address owner to use Google sign-in or follow a confirmation link.
Does disabling registrations prevent this issue?
No. The Google sign-in path can create accounts even when registrations are closed.
Which user actions can trigger the account-sharing condition?
A victim can trigger it by signing in with Google when their email matches an existing account that is not linked to Google, or by following an email confirmation link. The affected flows then sign the user into that account and can link Google or mark the email confirmed.
Are unconfirmed accounts able to obtain API access?
Yes. The API password sign-in endpoint issues tokens to accounts whose email has never been confirmed.
What access does the attacker obtain?
The attacker gains only the access that is granted to the victim afterward. The attacker keeps the password for the account created or changed to use the victim's address.