Vulnerable code

packages/core/src/service/helpers/external-authentication/external-authentication.service.ts — createCustomerAndUser:

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 CUSTOMER_VERIFIED 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 [email protected].
2. Attacker authenticates through an external provider configured on the store, presenting emailAddress = [email protected] 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:

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.