Vendure Account Takeover Flaw: External Auth Can Bind Attacker Identity to Victim Accounts by Email Alone

What happened

A critical security advisory (GHSA-6j36-r6pr-59x4, tracked as CVE-2026-63472, CVSS 9.1) was published for @vendure/core, the backend package for the Vendure e-commerce platform. According to the advisory, the ExternalAuthenticationService.createCustomerAndUser() method links a new external (OAuth/social) login to a pre-existing customer account by matching email address alone — without requiring that the email be verified as owned by that external identity. A public proof-of-concept is noted as available.

The advisory is explicit that this only affects stores that configure a custom AuthenticationStrategy (external/social/SSO login) which can forward an email address without guaranteeing the provider verified it — for example, ignoring an email_verified claim or leaving verified unset. Stores using only native email/password auth, or whose external strategies strictly enforce provider-verified emails, are stated as not affected.

Why it matters

Where the precondition holds, the advisory describes a straightforward account-takeover path: an attacker registers with an external provider using a victim's known email address, authenticates, and Vendure attaches the attacker's external authentication method to the victim's existing account. From that point the attacker can log in as the victim and access their orders, addresses, and other PII, or place orders in their name. The vendor's fix, shipped in Vendure 3.7.0, gates account-linking on a verified email.

What defenders should do now

• Inventory whether your Vendure deployment uses any custom AuthenticationStrategy beyond the built-in native strategy — this issue does not apply otherwise.
• If external/social auth is in use, upgrade @vendure/core to 3.7.0 as soon as possible.
• Until patched, audit each custom strategy's handling of email verification — confirm it checks the provider's verified-email claim (e.g. email_verified) before setting verified: true, and consider temporarily disabling strategies that can't make that guarantee.
• From a hunting perspective, review authentication/audit logs for new external authentication methods being attached to long-lived customer accounts shortly after account creation at the external provider, or multiple external identities converging on a single existing account without an explicit account-linking flow initiated by a logged-in user.

Developing intel

This is a same-day advisory disclosure and analysis based solely on the published GitHub Security Advisory; details may be refined as the community and vendor provide further guidance. For the full technical writeup, vulnerable code, and remediation, see the original GHSA advisory.