All Docs
FeaturesCalmony PayUpdated March 15, 2026

Security Fix: OAuth Account Linking Vulnerability (SEC-03)

Security Fix: OAuth Account Linking Vulnerability (SEC-03)

Version: 1.0.51
Severity: High
OWASP Category: Broken Authentication / Account Takeover
Affected file: src/platform/auth/providers.ts

What Was the Problem?

All four OAuth providers configured in Calmony Pay — Google, GitHub, Microsoft Entra, and Okta — had the allowDangerousEmailAccountLinking: true option set.

This flag instructs the authentication layer to automatically merge any incoming OAuth identity with an existing account that shares the same email address, without requiring any confirmation from the existing account holder.

Why This Is Dangerous

Automatic email-based account merging creates a direct account takeover path:

  1. A victim has an existing account linked to their Google identity (alice@example.com).
  2. An attacker registers a GitHub account using the same email address (alice@example.com). GitHub does not require email confirmation before OAuth sign-in is permitted in all configurations.
  3. The attacker signs into Calmony Pay using GitHub OAuth.
  4. Because allowDangerousEmailAccountLinking was enabled, the platform silently merges the attacker's GitHub session into the victim's existing account.
  5. The attacker now has full access to the victim's account — including payment methods, invoices, and subscription data.

This attack requires no interaction from the victim and leaves no obvious audit trail.

What Changed in v1.0.51

allowDangerousEmailAccountLinking: true has been removed from all four provider configurations:

// src/platform/auth/providers.ts

// Google
- allowDangerousEmailAccountLinking: true

// GitHub
- allowDangerousEmailAccountLinking: true

// Microsoft Entra
- allowDangerousEmailAccountLinking: true

// Okta
- allowDangerousEmailAccountLinking: true

With this flag absent (or explicitly set to false), the authentication layer will not automatically merge accounts. If a user attempts to sign in with an OAuth provider whose email matches an existing account registered via a different provider, they will be treated as a separate identity rather than silently granted access to the existing account.

Impact on Existing Users

Users who previously relied on automatic cross-provider merging to access a single account will need to sign in with the provider they originally used to create that account.

If your deployment requires cross-provider account linking, see the guidance below before re-enabling any merging behaviour.

Safe Alternatives to allowDangerousEmailAccountLinking

Do not re-enable allowDangerousEmailAccountLinking: true. Instead, consider the following approaches:

1. Explicit User-Consent Linking (Recommended)

Implement a provider-linking flow that requires the user to already be authenticated before they can attach a second OAuth provider to their account. The flow should:

  • Require an active session for the primary account before initiating the link.
  • Present a clear confirmation screen explaining which providers will be connected.
  • Record a consent timestamp and the linking actor in the audit log.

This ensures that only the legitimate account owner can attach additional providers.

2. Restrict Linking to Verified-Email Providers Only

If a lightweight linking approach is acceptable, restrict automatic merging to providers that guarantee email verification before issuing an OAuth token. Ensure your implementation checks the email_verified claim (or equivalent) in the provider's identity token and rejects merge attempts where this claim is absent or false.

3. No Cross-Provider Linking

For the highest assurance, treat each provider as a fully independent identity. Users who want to sign in with a different provider must create a new account or use an explicit account-migration flow managed by your support team.

References