# CVE-2026-63472: Vendure affected by external-authentication account takeover: external login linked to a pre-existing account by email without verification

> CVE-2026-63472 (GitHub advisory GHSA-6j36-r6pr-59x4) is a critical-severity vulnerability with a CVSS 3.1 base score of 9.1, classed as Improper Authentication (CWE-287), in @vendure/core (npm). Affected versions: < 3.7.0. It is fixed in 3.7.0.

Canonical page: https://cveminer.com/vulnerabilities/CVE-2026-63472

| Field | Value |
| --- | --- |
| CVE | CVE-2026-63472 |
| GHSA | GHSA-6j36-r6pr-59x4 |
| Severity | Critical |
| CVSS 3.1 | 9.1 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N` (GitHub Advisory Database) |
| CWE | CWE-287 Improper Authentication |
| EPSS | 0.41% (higher than 35% of CVEs) |
| CISA KEV | Not listed |
| SSVC | exploitation poc, automatable yes, technical impact total |
| Published | 17 Sept 2026 |
| Modified | 17 Sept 2026 |

## Description

### 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.

## Affected packages

| Package | Ecosystem | PURL | Vulnerable versions | Fixed in |
| --- | --- | --- | --- | --- |
| @vendure/core | npm | `pkg:npm/%40vendure/core` | < 3.7.0 | 3.7.0 |

## Fix commits

- Patch: https://github.com/vendurehq/vendure/commit/3bb04718ea4f9395fda731bd2a4bcfc3afb0a485
- Release: https://github.com/vendurehq/vendure/commit/a2b8ff8b33b1d241b244b0072870569feae80135 (3.7.0)

## Questions

**What is the GHSA ID for CVE-2026-63472?**

GitHub tracks CVE-2026-63472 as GHSA-6j36-r6pr-59x4.

**What is the CVSS score of CVE-2026-63472?**

CVE-2026-63472 has a CVSS 3.1 base score of 9.1 (Critical), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.

**Which versions are affected by CVE-2026-63472?**

@vendure/core (npm): < 3.7.0.

**How do I fix CVE-2026-63472?**

Upgrade to 3.7.0 or later. The fix is in commit 3bb0471.

**What is the Package URL (PURL) for CVE-2026-63472?**

The affected package's PURL is pkg:npm/%40vendure/core.

**Is CVE-2026-63472 exploited in the wild?**

CISA's Known Exploited Vulnerabilities catalog doesn't list CVE-2026-63472. That means no confirmed exploitation has been catalogued, not that it is safe to leave unpatched. CISA's SSVC assessment rates exploitation as "poc". EPSS estimates a 0.41% chance of exploitation in the next 30 days, higher than 35% of CVEs.

## References

- https://github.com/vendurehq/vendure/commit/3bb04718ea4f9395fda731bd2a4bcfc3afb0a485 (fix)
- https://github.com/vendurehq/vendure/security/advisories/GHSA-6j36-r6pr-59x4 (advisory)
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/63xxx/CVE-2026-63472.json (advisory)
- https://nvd.nist.gov/vuln/detail/CVE-2026-63472 (advisory)
- https://github.com/advisories/GHSA-6j36-r6pr-59x4 (advisory)
- https://github.com/vendurehq/vendure (package)
- https://github.com/vendurehq/vendure/releases/tag/v3.7.0

---

Source: CVEminer (https://cveminer.com/vulnerabilities/CVE-2026-63472), compiled from OSV (GitHub advisory), GitHub Advisory Database, OSV (CVE record), CVE.org, CISA KEV catalog. OSV and GitHub Advisory Database content is licensed CC BY 4.0.