Summary
Vendure affected by external-authentication account takeover: external login linked to a pre-existing account by email without verification
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
AuthenticationStrategyimplementations
(custom OAuth / social login / SSO), and - At least one forwards an
emailAddresstoExternalAuthenticationServicewithout
guaranteeing the provider verified ownership of it (e.g. it doesn't check the provider'semail_verifiedclaim, or leavesverifiedunset/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 setverified: true only for emails the provider has actually verified.
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 email_verified 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:
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.
Reproduction (conceptual)
- Victim has a native Vendure customer account
[email protected]. - Attacker authenticates through an external provider configured on the store, presenting
emailAddress = [email protected]withverifiedunset/false (depending on the strategy/provider). createCustomerAndUserfinds the victim's existing User by email and attaches the attacker'sExternalAuthenticationMethod.- Attacker logs in via that external method → authenticated as the victim.
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.
The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.
CVE-2026-63472 has a CVSS score of 9.1 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.7.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-63472? CVE-2026-63472 is a critical-severity improper authentication vulnerability in @vendure/core (npm), affecting versions < 3.7.0. It is fixed in 3.7.0. The application does not adequately verify the identity of a user, device, or process before granting access.
- How severe is CVE-2026-63472? CVE-2026-63472 has a CVSS score of 9.1 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of @vendure/core are affected by CVE-2026-63472? @vendure/core (npm) versions < 3.7.0 is affected.
- Is there a fix for CVE-2026-63472? Yes. CVE-2026-63472 is fixed in 3.7.0. Upgrade to this version or later.
- Is CVE-2026-63472 exploitable, and should I be worried? Whether CVE-2026-63472 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-63472 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-63472? Upgrade
@vendure/coreto 3.7.0 or later.