All Docs
FeaturesMaking Tax DigitalUpdated February 24, 2026

Security Advisory: OAuth Account Takeover via allowDangerousEmailAccountLinking

Security Advisory: OAuth Account Takeover via allowDangerousEmailAccountLinking

Severity: Critical
Fixed in: v1.0.38
Affected versions: All versions prior to v1.0.38
Affected file: src/platform/auth/providers.ts

Summary

A critical account takeover vulnerability was identified and resolved in v1.0.38. All four OAuth providers configured in the platform — Google, GitHub, Microsoft, and Okta — had allowDangerousEmailAccountLinking: true set. This option bypasses identity verification during OAuth account linking, enabling an attacker to take over any existing user account by simply controlling an OAuth provider account registered with the victim's email address.

Given that this platform processes HMRC Making Tax Digital (MTD) submissions, National Insurance Numbers, and financial transaction data sourced from AgentOS landlord records, a successful account takeover could expose highly sensitive personal and financial information and compromise tax filing integrity.

Vulnerability Detail

Root Cause

allowDangerousEmailAccountLinking: true instructs the OAuth library to automatically merge an inbound OAuth identity into any existing local account that shares the same email address — regardless of whether the person initiating the OAuth login has previously authenticated with that local account.

This was set on all four providers:

// src/platform/auth/providers.ts — VULNERABLE (pre-v1.0.38)
GoogleProvider({
  // ...
  allowDangerousEmailAccountLinking: true,
}),
GitHubProvider({
  // ...
  allowDangerousEmailAccountLinking: true,
}),
MicrosoftProvider({
  // ...
  allowDangerousEmailAccountLinking: true,
}),
OktaProvider({
  // ...
  allowDangerousEmailAccountLinking: true,
}),

Attack Scenario

  1. Victim has a registered account on the platform using victim@example.com.
  2. Attacker registers (or already controls) a Google, GitHub, Microsoft, or Okta account using victim@example.com.
  3. Attacker visits the platform and initiates OAuth login with that provider account.
  4. The platform automatically links the attacker's OAuth identity to the victim's existing account and starts a session as the victim.
  5. Attacker gains full access to the victim's HMRC submissions, National Insurance Number, and AgentOS-imported financial records.

Resolution

The allowDangerousEmailAccountLinking: true flag has been removed from all four OAuth provider configurations in v1.0.38.

In its place, a secure, session-gated account linking flow has been implemented. The key principles of the new approach are:

  • A user must already be authenticated in an active session before they can link an additional OAuth provider to their account.
  • OAuth login for a new provider is only permitted to link to an existing account when initiated from within an authenticated session, confirming the requesting user already owns that account.
  • Unauthenticated OAuth logins that match an existing account's email will not automatically link or grant access to that account.

Impact Assessment

DimensionAssessment
ConfidentialityCritical — NI Numbers, HMRC submission data, financial records exposed
IntegrityCritical — Attacker could file or modify HMRC MTD submissions
AvailabilityHigh — Attacker could alter or delete account data
RegulatoryCritical — Potential breach of HMRC MTD obligations and UK GDPR

Recommended Actions for Platform Administrators

  1. Deploy v1.0.38 immediately to all environments.
  2. Audit OAuth-linked accounts created prior to v1.0.38 for any suspicious or unexpected provider links, particularly accounts where a secondary provider was linked without a corresponding user-initiated action.
  3. Review access logs for any accounts that may have been accessed via OAuth login from an unexpected provider.
  4. Notify affected users if evidence of unauthorised account linking is found, in accordance with your UK GDPR breach notification obligations.

References