CVE-2026-63472: @vendure/core External Login Linked To A Vulnerability

CRITICAL
Advisory Identifier: GHSA-6j36-r6pr-59x4
CVSS 9.1
CWE-287
Published
Advisory Summary

CVE-2026-63472 is a CRITICAL (CVSS 9.1) external login linked to a vulnerability (CWE-287: Improper Authentication) affecting @vendure/core libraries in the npm ecosystem. The issue involves external login linked to a pre-existing account by email without verification. Remediation is available by upgrading affected packages to version 3.7.0.

CVE-2026-63472 at a Glance

CVE Identifier CVE-2026-63472
GHSA Identifier GHSA-6j36-r6pr-59x4
Severity CRITICAL
CVSS v3.1 Base Score 9.1
CWE Classification CWE-287: Improper Authentication
Affected Product @vendure/core
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 9.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2026-63472

To remediate this vulnerability, upgrade all affected @vendure/core dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

@vendure/core fixed: 3.7.0
npm install @vendure/core@3.7.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls @vendure/core

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-63472, inspect your project dependencies using npm:

npm ls @vendure/core

Analyze the terminal output to locate any version of @vendure/core in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.7.0), your application is affected.

Note: The npm ls @vendure/core command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-287: Improper Authentication, where when an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. In @vendure/core, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

# 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 `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`: ```ts 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 `victim@example.com`. 2. Attacker authenticates through an external provider configured on the store, presenting `emailAddress = victim@example.com` 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: ```ts 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.

CVE-2026-63472 Affected @vendure/core Versions

1 component(s)
Fixed Versions:
3.7.0
Product / Package Ecosystem Affected Versions Fixed Version
@vendure/core
npm
< 3.7.0
3.7.0

References

Frequently Asked Questions

What is CVE-2026-63472?
CVE-2026-63472 is a security vulnerability in @vendure/core involving external login linked to a pre-existing account by email without verification under CWE-287: Improper Authentication.
Which @vendure/core versions are affected?
Affected versions include releases prior to 3.7.0 across affected packages: @vendure/core.
What version fixes CVE-2026-63472?
Upgrading to 3.7.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @vendure/core affected?
Yes, @vendure/core is affected in releases prior to 3.7.0. Upgrade your dependency to 3.7.0 or later.
What is the CVSS score of CVE-2026-63472?
CVE-2026-63472 has a CVSS v3.1 base score of 9.1 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
What CWE is associated with CVE-2026-63472?
CVE-2026-63472 is classified under CWE-287: Improper Authentication (When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.).
How can I check npm dependencies for CVE-2026-63472?
Run the dependency tree command: 'npm ls @vendure/core'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-6j36-r6pr-59x4",
  "modified" : "2026-09-17T14:50:22Z",
  "published" : "2026-09-17T14:50:22Z",
  "aliases" : [ "CVE-2026-63472" ],
  "summary" : "Vendure affected by external-authentication account takeover: external login linked to a pre-existing account by email without verification",
  "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) · \n\n> [!IMPORTANT]\n> 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;                 // <-- 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];   // <-- 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@vendure/core"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.7.0"
      } ]
    } ]
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-287" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-17T14:50:22Z",
    "nvd_published_at" : null
  }
}