{"id":"CVE-2026-63472","aliases":["EUVD-2026-81668","GHSA-6j36-r6pr-59x4"],"status":"published","title":"Vendure: External-authentication account takeover: external login linked to a pre-existing account by email without verification","description":"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.","severity":{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00589,"percentile":0.48675,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-287"],"published":"2026-09-17T14:40:31Z","modified":"2026-10-28T02:31:14Z","fixes":[{"ecosystem":"npm","package":"@vendure/core","fixed_in":["3.7.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"@vendure/core","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.7.0"}]}]},{"source":"osv","ecosystem":"npm","package":"@vendure/core","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"3.7.0"}]}]}],"products":[{"vendor":"vendurehq","product":"vendure"}],"references":[{"url":"https://github.com/vendurehq/vendure/security/advisories/GHSA-6j36-r6pr-59x4","tags":["x_refsource_CONFIRM","exploit","advisory","web"]},{"url":"https://github.com/vendurehq/vendure/commit/3bb04718ea4f9395fda731bd2a4bcfc3afb0a485","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/vendurehq/vendure/releases/tag/v3.7.0","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-6j36-r6pr-59x4"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/63xxx/CVE-2026-63472.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-63472","tags":["advisory"]},{"url":"https://github.com/vendurehq/vendure","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-63472","title":"Vendure: External-authentication account takeover: external login linked to a pre-existing account by email without verification","description":"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.","status":"published","published":"2026-09-17T14:40:31.353Z","modified":"2026-09-17T15:21:11.192Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical","assessor":"cna"}],"cwes":["CWE-287"],"updated_at":"2026-11-02T14:19:55.914391Z"}],"euvd":[{"id":"EUVD-2026-81668","description":"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.","status":"published","published":"2026-09-17T14:40:31Z","modified":"2026-09-17T15:21:11Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical"}],"updated_at":"2026-11-02T17:28:11.273554Z"}],"ghsa":[{"id":"GHSA-6j36-r6pr-59x4","title":"Vendure affected by external-authentication account takeover: external login linked to a pre-existing account by email without verification","description":"# 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) · \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't check the provider's\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 — 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.\n\n## Vulnerable code\n`packages/core/src/service/helpers/external-authentication/external-authentication.service.ts` — `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) — 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.\n\n## Impact\nAccount 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.\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's existing User by email and attaches the attacker's `ExternalAuthenticationMethod`.\n4. Attacker logs in via that external method → 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.","status":"published","published":"2026-09-17T14:50:22Z","modified":"2026-09-17T14:50:24Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical"}],"cwes":["CWE-287"],"updated_at":"2026-11-02T14:41:17.136201Z"}],"nvd":[{"id":"CVE-2026-63472","description":"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.","status":"published","published":"2026-09-17T15:16:49.743Z","modified":"2026-09-17T21:16:02.56Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical","assessor":"secondary"}],"cwes":["CWE-287"],"updated_at":"2026-11-02T14:12:49.013904Z"}],"osv":[{"id":"CVE-2026-63472","title":"Vendure: External-authentication account takeover: external login linked to a pre-existing account by email without verification","description":"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.","status":"published","published":"2026-09-17T14:40:31.353Z","modified":"2026-10-28T02:31:14.311992304Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical"}],"cwes":["CWE-287"],"updated_at":"2026-11-02T15:45:13.306117Z"},{"id":"GHSA-6j36-r6pr-59x4","title":"Vendure affected by external-authentication account takeover: external login linked to a pre-existing account by email without verification","description":"# 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) · \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't check the provider's\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 — 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.\n\n## Vulnerable code\n`packages/core/src/service/helpers/external-authentication/external-authentication.service.ts` — `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) — 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.\n\n## Impact\nAccount 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.\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's existing User by email and attaches the attacker's `ExternalAuthenticationMethod`.\n4. Attacker logs in via that external method → 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.","status":"published","published":"2026-09-17T14:50:22Z","modified":"2026-09-17T15:00:06.681857527Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical"}],"cwes":["CWE-287"],"updated_at":"2026-11-02T15:46:39.965326Z"}]}}