Vendure is an open-source headless commerce platform. Prior to 3.7.0, ExternalAuthenticationService.createCustomerAndUser in packages/core/src/service/helpers/external-authentication/external-authentication.service.ts selects an existing customer user by emailAddress and attaches a newly presented ExternalAuthenticationMethod without requiring verified to be true. In deployments with a custom external AuthenticationStrategy that forwards an email whose ownership the provider has not verified, an attacker can authenticate with a victim's email and bind the attacker's external identity to the victim's existing account. This can expose orders, addresses, and personal information and permit account changes or orders as the victim. Native-only email and password deployments and external strategies that always require provider-verified email ownership are unaffected, and new-account creation for an unused email remains permitted. This issue is fixed in version 3.7.0.

Affected: npm: @vendure/core

# External-authentication account takeover: external login linked to a pre-existing account by email without requiring verification

**Package:** @vendure/core (vendure-ecommerce/vendure, latest master) ·

> [!IMPORTANT] > This vulnerability **only affects deployments that use external / social authentication** (an `AuthenticationStrategy` other than the built-in native email/password strategy) where that strategy can return an email address the external provider has **not verified** the user owns.

**You are affected if all of these are true:** - Your store configures one or more external `AuthenticationStrategy` implementations (custom OAuth / social login / SSO), **and** - At least one forwards an `emailAddress` to `ExternalAuthenticationService` without guaranteeing the provider verified ownership of it (e.g. it doesn't check the provider's `email_verified` claim, or leaves `verified` unset/false), **and** - Customer accounts exist that share an email address with those external identities.

**You are NOT affected if:** - You use only the built-in native (email/password) authentication with no external strategies, **or** - Every external strategy you use only ever returns provider-verified emails (and sets `verified: true`).

**Remediation:** Upgrade to **3.7.0**. After upgrading, an external login is only linked to a pre-existing account when the email is verified; a custom `AuthenticationStrategy` must set `verified: true` only for emails the provider has actual…