GHSA-6J36-R6PR-59X4
Vulnerability from github – Published: 2026-09-17 14:50 – Updated: 2026-09-17 14:50External-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
AuthenticationStrategyother 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 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 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.
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)
- Victim has a native Vendure customer account
victim@example.com. - Attacker authenticates through an external provider configured on the store, presenting
emailAddress = victim@example.comwithverifiedunset/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.
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.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@vendure/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.7.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-63472"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T14:50:22Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "# External-authentication account takeover: external login linked to a pre-existing account by email without requiring verification\n\n**Package:** @vendure/core (vendure-ecommerce/vendure, latest master) \u00b7 \n\n\u003e [!IMPORTANT]\n\u003e This vulnerability **only affects deployments that use external / social authentication**\n(an `AuthenticationStrategy` other than the built-in native email/password strategy) where\nthat strategy can return an email address the external provider has **not verified** the\nuser owns.\n\n**You are affected if all of these are true:**\n- Your store configures one or more external `AuthenticationStrategy` implementations\n (custom OAuth / social login / SSO), **and**\n- At least one forwards an `emailAddress` to `ExternalAuthenticationService` without\n guaranteeing the provider verified ownership of it (e.g. it doesn\u0027t check the provider\u0027s\n `email_verified` claim, or leaves `verified` unset/false), **and**\n- Customer accounts exist that share an email address with those external identities.\n\n**You are NOT affected if:**\n- You use only the built-in native (email/password) authentication with no external strategies, **or**\n- Every external strategy you use only ever returns provider-verified emails (and sets `verified: true`).\n\n**Remediation:** Upgrade to **3.7.0**. After upgrading, an external login is only linked to a\npre-existing account when the email is verified; a custom `AuthenticationStrategy` must set\n`verified: true` only for emails the provider has actually verified.\n\n## Summary\n`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 \u2014 common with custom OAuth providers, or providers/strategies that don\u0027t validate email ownership), an attacker can register at that provider using a victim\u0027s email address, authenticate, and have their external identity bound to the victim\u0027s existing Vendure account \u2014 resulting in account takeover.\n\n## Vulnerable code\n`packages/core/src/service/helpers/external-authentication/external-authentication.service.ts` \u2014 `createCustomerAndUser`:\n```ts\nconst existingUser = await this.findExistingCustomerUserByEmailAddress(ctx, config.emailAddress);\nif (existingUser) {\n user = existingUser; // \u003c-- links to the EXISTING account, by email alone\n} else {\n user = new User({ identifier: config.emailAddress, verified: config.verified || false, ... });\n}\nconst authMethod = await this.connection.getRepository(ctx, ExternalAuthenticationMethod).save(\n new ExternalAuthenticationMethod({ externalIdentifier: config.externalIdentifier, strategy: config.strategy }),\n);\nuser.authenticationMethods = [...(user.authenticationMethods || []), authMethod]; // \u003c-- external login attached\nawait this.connection.getRepository(ctx, User).save(user);\n```\n`config.verified` is used only to set `User.verified` and to write a `CUSTOMER_VERIFIED` history entry (later in the method) \u2014 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\u0027s account just the same.\n\n## Impact\nAccount takeover of any customer whose email address an attacker can present (unverified) via an external auth provider \u2014 read/modify the victim\u0027s orders, addresses, and PII, and place orders as them. The blast radius depends on the deployed `AuthenticationStrategy`(ies): strategies that don\u0027t strictly require a provider-verified email (or providers that don\u0027t guarantee email ownership) are directly exploitable.\n\n## Reproduction (conceptual)\n1. Victim has a native Vendure customer account `victim@example.com`.\n2. Attacker authenticates through an external provider configured on the store, presenting `emailAddress = victim@example.com` with `verified` unset/false (depending on the strategy/provider).\n3. `createCustomerAndUser` finds the victim\u0027s existing User by email and attaches the attacker\u0027s `ExternalAuthenticationMethod`.\n4. Attacker logs in via that external method \u2192 authenticated as the victim.\n\n## Suggested fix\nRefuse to bind an external authentication method to a **pre-existing** account unless the email is provably verified, and prefer explicit, authenticated account-linking:\n```ts\nif (existingUser) {\n if (!config.verified) {\n // Do not silently link an unverified external identity to an existing account.\n throw new EmailAddressConflictError(); // or require the user to link while logged in\n }\n user = existingUser;\n}\n```\nDocument clearly that an `AuthenticationStrategy` MUST only set `verified: true` for provider-verified emails, and that linking to existing accounts requires it.",
"id": "GHSA-6j36-r6pr-59x4",
"modified": "2026-09-17T14:50:22Z",
"published": "2026-09-17T14:50:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vendurehq/vendure/security/advisories/GHSA-6j36-r6pr-59x4"
},
{
"type": "WEB",
"url": "https://github.com/vendurehq/vendure/commit/3bb04718ea4f9395fda731bd2a4bcfc3afb0a485"
},
{
"type": "PACKAGE",
"url": "https://github.com/vendurehq/vendure"
},
{
"type": "WEB",
"url": "https://github.com/vendurehq/vendure/releases/tag/v3.7.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Vendure affected by external-authentication account takeover: external login linked to a pre-existing account by email without verification"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.