Improper authentication lets Google sign-in and confirmation links sign users in to accounts registered with their email address by someone else
Summary
| CVE | CVE-2026-120999 |
|---|---|
| State | PUBLISHED |
| Assigner | EEF |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-11-10 11:16:42 UTC |
| Updated | 2026-11-10 11:16:42 UTC |
| Description | Improper Authentication vulnerability in Google sign-in and email confirmation in nerves-hub nerves_hub_web allows an attacker who registers another person's email address to share that person's account once they sign in. NervesHub.Accounts.update_or_create_user_from_ueberauth/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 email_verified 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 nerves_hub: from 2.3.0 before 2.5.3. |
Risk And Classification
Primary CVSS: v4.0 7.4 HIGH from 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Problem Types: CWE-287 | CWE-345 | CWE-287 CWE-287 Improper Authentication | CWE-345 CWE-345 Insufficient Verification of Data Authenticity
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 4.0 | 6b3ad84c-e1a6-4bf7-a703-f496b71e49db | Secondary | 7.4 | HIGH | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/C... |
| 4.0 | CNA | CVSS | 7.4 | HIGH | CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N |
CVSS v4.0 Breakdown
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Nerves-hub | Nerves Hub Web | affected 2.3.0 2.5.3 other | Not specified |
| CNA | Nerves-hub | Nerves Hub Web | affected 2.3.0 2.5.3 semver | Not specified |
| CNA | Nerves-hub | Nerves Hub Web | affected 74982672ab914bd6f37c3bc0e24a06e3474fa030 54dbf93c3bd323df08223a853c9afcf0b4dbf8e4 git | Not specified |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| github.com/nerves-hub/nerves_hub_web/commit/54dbf93c3bd323df08223a853c9a... | 6b3ad84c-e1a6-4bf7-a703-f496b71e49db | github.com | |
| github.com/nerves-hub/nerves_hub_web/security/advisories/GHSA-r92p-gg92-... | 6b3ad84c-e1a6-4bf7-a703-f496b71e49db | github.com | |
| cna.erlef.org/cves/CVE-2026-120999.html | 6b3ad84c-e1a6-4bf7-a703-f496b71e49db | cna.erlef.org | |
| github.com/nerves-hub/nerves_hub_web/commit/74982672ab914bd6f37c3bc0e24a... | 6b3ad84c-e1a6-4bf7-a703-f496b71e49db | github.com | |
| osv.dev/vulnerability/EEF-CVE-2026-120999 | 6b3ad84c-e1a6-4bf7-a703-f496b71e49db | osv.dev | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
Vendor Comments And Credit
Discovery Credit
CNA: Josh Kalderimis (en)
CNA: Jonatan Männchen / EEF (en)
Additional Advisory Data
Solutions
CNA: Upgrading does not undo links already made. Review the users rows that carry both a password_hash and a google_id; most are one person signing in both ways, but an account registered for someone else's address was usually created well before its first Google sign-in, so compare inserted_at with google_last_synced_at. For one its owner did not set up, set its google_id to NULL, delete its user_tokens rows to end its sessions and revoke its API tokens, and have the address's owner reset the password. An account taken through a confirmation link looks the same as one its owner set up; its owner can end anyone else's access by resetting the password, which ends every session and revokes every API token. Before upgrading, check how your instance lets people sign up: SIGN_UP_METHODS replaces OPEN_FOR_REGISTRATIONS, and instances that relied on Google sign-in to create accounts while registrations were off need SIGN_UP_METHODS=google.
Workarounds
CNA: Turn off Google sign-in by unsetting GOOGLE_CLIENT_ID until the upgrade; users who only sign in with Google cannot sign in while it is off. This does not close the confirmation link path. Turning off registrations stops strangers using the sign-up form, but not an organization admin registering from an invite link.