GHSA-6j36-r6pr-59x4: Critical severity npm/@vendure/core vulnerability

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 emailverified 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 actually verified.

Summary ExternalAuthenticationService.createCustomerAndUser() links a newly-presented external (OAuth/social) authentication method to a pre-existing User account selected purely by email-address match, and it does so without requiring config.verified === true. If any configured AuthenticationStrategy forwards an email that was not proven to belong to the external identity (the classic emailverified omission — common with custom OAuth providers, or providers/strategies that don't validate email ownership), an attacker can register at that provider using a victim's email address, authenticate, and have their external identity bound to the victim's existing Vendure account — resulting in account takeover.

Vulnerable code packages/core/src/service/helpers/external-authentication/external-authentication.service.ts — createCustomerAndUser: ts const existingUser = await this.findExistingCustomerUserByEmailAddress(ctx, config.emailAddress); if (existingUser) { user = existingUser; // <-- links to the EXISTING account, by email alone } else { user = new User({ identifier: config.emailAddress, verified: config.verified || false, ... }); } const authMethod = await this.connection.getRepository(ctx, ExternalAuthenticationMethod).save( new ExternalAuthenticationMethod({ externalIdentifier: config.externalIdentifier, strategy: config.strategy }), ); user.authenticationMethods = [...(user.authenticationMethods || []), authMethod]; // <-- external login attached await this.connection.getRepository(ctx, User).save(user); config.verified is used only to set User.verified and to write a CUSTOMERVERIFIED history entry (later in the method) — it is never used to gate whether the external method may be attached to an existing account. So an unverified external email links to the victim's account just the same.

Impact Account takeover of any customer whose email address an attacker can present (unverified) via an external auth provider — read/modify the victim's orders, addresses, and PII, and place orders as them. The blast radius depends on the deployed AuthenticationStrategy(ies): strategies that don't strictly require a provider-verified email (or providers that don't guarantee email ownership) are directly exploitable.

Reproduction (conceptual) 1. Victim has a native Vendure customer account victim@example.com. 2. Attacker authenticates through an external provider configured on the store, presenting emailAddress = victim@example.com with verified unset/false (depending on the strategy/provider). 3. createCustomerAndUser finds the victim's existing User by email and attaches the attacker's ExternalAuthenticationMethod. 4. Attacker logs in via that external method → authenticated as the victim.

Suggested fix Refuse to bind an external authentication method to a pre-existing account unless the email is provably verified, and prefer explicit, authenticated account-linking: ts if (existingUser) { if (!config.verified) { // Do not silently link an unverified external identity to an existing account. throw new EmailAddressConflictError(); // or require the user to link while logged in } user = existingUser; } Document clearly that an AuthenticationStrategy MUST only set verified: true for provider-verified emails, and that linking to existing accounts requires it.