All Docs
FeaturesCalmony Sanctions MonitorUpdated March 12, 2026

Security Advisory SEC-20: OAuth Account-Linking Vulnerability Fixed

Security Advisory SEC-20: OAuth Account-Linking Vulnerability Fixed

Release: v0.1.135
Severity: High
Category: Authentication & Session Security
Status: Resolved

Summary

Version 0.1.135 resolves a high-severity authentication vulnerability (SEC-20) in which all three OAuth providers — Google, GitHub, and Microsoft Entra ID — were configured with allowDangerousEmailAccountLinking: true. This setting has been removed from every provider configuration in src/lib/auth-providers.ts.

Background

The platform supports sign-in via three OAuth 2.0 providers. Prior to this release, each provider was configured with the following flag:

// BEFORE — vulnerable configuration (src/lib/auth-providers.ts)
GoogleProvider({
  clientId: process.env.GOOGLE_CLIENT_ID,
  clientSecret: process.env.GOOGLE_CLIENT_SECRET,
  allowDangerousEmailAccountLinking: true, // ⚠️ removed in v0.1.135
})

GitHubProvider({
  clientId: process.env.GITHUB_CLIENT_ID,
  clientSecret: process.env.GITHUB_CLIENT_SECRET,
  allowDangerousEmailAccountLinking: true, // ⚠️ removed in v0.1.135
})

MicrosoftEntraIDProvider({
  clientId: process.env.ENTRA_CLIENT_ID,
  clientSecret: process.env.ENTRA_CLIENT_SECRET,
  allowDangerousEmailAccountLinking: true, // ⚠️ removed in v0.1.135
})

Vulnerability Details

Attack vector

allowDangerousEmailAccountLinking: true instructs the authentication library to automatically merge an incoming OAuth sign-in with any existing database account that shares the same email address — without additional verification.

An attacker who can control or compromise any one of the three OAuth providers (for example, by registering a malicious OAuth app that returns an arbitrary email claim, or by exploiting a misconfiguration in the provider) can:

  1. Present a crafted OAuth token claiming a victim's email address.
  2. Have the platform silently link the attacker's OAuth identity to the victim's existing account.
  3. Gain full authenticated access to the victim's session, including sanctions-screening data, watchlists, and audit history.

Why this is especially serious here

This platform processes OFSI-mandated sanctions data and supports UK financial compliance workflows. An account takeover in this context may:

  • Expose sensitive PEP and sanctions-screening results.
  • Allow manipulation of monitored entity lists or alert statuses.
  • Constitute a reportable breach under UK GDPR and FCA guidelines.
  • Undermine the integrity of audit trails required for regulatory accountability.

Resolution

What was changed

The allowDangerousEmailAccountLinking: true flag has been removed from all three provider configurations:

// AFTER — secure configuration (src/lib/auth-providers.ts)
GoogleProvider({
  clientId: process.env.GOOGLE_CLIENT_ID,
  clientSecret: process.env.GOOGLE_CLIENT_SECRET,
  // allowDangerousEmailAccountLinking removed
})

GitHubProvider({
  clientId: process.env.GITHUB_CLIENT_ID,
  clientSecret: process.env.GITHUB_CLIENT_SECRET,
  // allowDangerousEmailAccountLinking removed
})

MicrosoftEntraIDProvider({
  clientId: process.env.ENTRA_CLIENT_ID,
  clientSecret: process.env.ENTRA_CLIENT_SECRET,
  // allowDangerousEmailAccountLinking removed
})

Behaviour after this change

  • If a user attempts to sign in via an OAuth provider whose email matches an existing account registered under a different provider, the sign-in will be rejected rather than silently linked.
  • Users are protected from cross-provider account merging unless a future explicit, verified linking flow is implemented.

If You Need Multi-Provider Linking

If your compliance team requires a single user account to be accessible via multiple OAuth providers, do not re-enable allowDangerousEmailAccountLinking. Instead, implement account linking through a controlled flow that includes:

  1. Explicit user confirmation — the authenticated user must actively approve the link from within their session.
  2. Email verification — send a confirmation to the address being linked before completing the merge.
  3. Audit logging — record the linking event (actor, timestamp, provider, IP address) to the platform audit trail.

Action Required for Self-Hosted Instances

If you run a self-hosted or forked deployment:

  1. Apply this patch immediately — update src/lib/auth-providers.ts to remove allowDangerousEmailAccountLinking: true from all provider objects and redeploy.
  2. Review your audit logs — check for unexpected account-linking events that may indicate exploitation prior to this patch.
  3. Rotate affected credentials — if you suspect an account may have been compromised, invalidate active sessions and require re-authentication.

References

  • Internal control: SEC-20
  • Affected file: src/lib/auth-providers.ts
  • Release: v0.1.135 Changelog