Because a mutable email claim can let an attacker present the same address as a legitimate user and trigger an incorrect merge. Once that merge happens, the attacker inherits the victim’s identity context and can impersonate them inside the application. The risk is not OAuth itself, but trusting provider data that is not a reliable unique identifier.
Why unverified email is a weak merge key
An email address is often treated as a convenient lookup field, but it is not a trustworthy proof of identity unless the application has independently verified that the claimant controls it. In OAuth flows, the provider may return an email claim that looks consistent and still be unsuitable as the sole basis for account linking, especially when the same address can be reassigned, spoofed at the application layer, or exposed through a compromised third-party identity path.
The core design mistake is confusing a profile attribute with an immutable identifier. A merge decision should be based on a stable, provider-backed subject identifier and a trust model that matches the application’s risk, not on a mutable field that can drift over time. That distinction is what keeps identity correlation from becoming identity substitution.
When applications merge accounts too aggressively, they collapse two security boundaries at once: the external identity proof and the internal application account history. Once the wrong merge occurs, the attacker does not need to break OAuth itself, because the application has already granted the attacker the victim’s local continuity, permissions, and session context.
For a practitioner view of identity provenance, lifecycle, and linkability, NHI Mgmt Group’s Ultimate Guide to NHIs is a useful reference point, and its discussion of token and OAuth-based identity relationships helps explain why the wrong correlation primitive creates downstream access risk.
How the takeover happens after a bad merge
The attack path is usually simple: an attacker obtains control of an OAuth account or account profile that presents the same email address as the target, then triggers an application flow that treats that email as proof of continuity. If the merge logic does not require a stronger binding check, the application may attach the attacker’s OAuth subject to the victim’s local account.
After that point, the attacker can inherit authorization decisions that were made for the victim, including saved preferences, active sessions, API access, linked devices, or delegated workflows. The dangerous part is that the application sees a seemingly legitimate authenticated user, while the actual trust relationship has been corrupted during account consolidation.
This pattern is closely related to broader token and account-abuse incidents, where the compromise is not in the protocol but in how the application interprets provider data. A useful parallel is the Salesloft OAuth token breach, which shows how trust in integration data can be turned into unauthorized downstream access. Another relevant example is the Microsoft OAuth Breach, where application abuse enabled persistent access rather than a simple login failure.
Where the account merge affects integrated services, the blast radius can widen quickly. If the victim account already has linked SaaS, admin features, or stored tokens, the merge can expose more than a single profile, it can expose an entire authorization graph.
Risk and Threat Considerations
Unverified-email account merging creates account takeover risk because it turns a non-unique, changeable attribute into an identity binding mechanism. That makes the application vulnerable to impersonation, especially when the attacker can control a mailbox, reuse a recycled address, or exploit any process that assumes matching email means matching person.
Failure mechanism: The merge logic accepts email equality as sufficient proof of identity continuity, then attaches the wrong external identity to the victim’s local account and its permissions.
Impact: The attacker can inherit application state, access protected data, act under the victim’s name, and potentially pivot into connected systems or delegated workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Binding and Subject Uniqueness | Email-based merges fail when the app lacks a stable binding between subject and account. |
| NHI-03 — Credential and Token Trust | OAuth claims and tokens are trust inputs here, so trust boundaries must be explicit. | |
| Recommendation — Bind accounts to immutable issuer subject IDs and require step-up verification before linking profiles. Validate provider assertions before using them to inherit access or merge identities. | ||
| CIS Controls v8 | 5.1 — Account Management | Account linking and merge logic are account-management decisions that can create takeover paths. |
| Recommendation — Review account creation, linking, and deprovisioning workflows for unsafe identity joins. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Credential Management | The issue is improper identity correlation and access assignment based on weak attributes. |
| Recommendation — Enforce identity proofing and access binding that do not rely on mutable email claims. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | A bad merge can let an attacker operate through a legitimate application account. |
| Recommendation — Hunt for misuse of valid accounts when account linking changes unexpected access paths. | ||
Practitioner Guidance
What to verify: Before allowing automatic linking, require a stable issuer subject identifier or a separately verified ownership step. If the application cannot prove that the same person controls both sides of the relationship, treat the merge as a high-risk exception rather than a routine convenience.
Decision rule: If the merge would grant access to existing data, sessions, or downstream integrations, do not use unverified email as the join key. Use email only as a contact attribute unless the provider and the application have an explicit, tested trust model for account correlation.
Common mistake: Teams often harden login but leave account linking under-reviewed. That is where takeover happens, because the attacker only needs to win the merge decision once.
Practitioner takeaway: Safe OAuth handling is not about distrusting OAuth, it is about refusing to let an unverified attribute decide who inherits an existing account.
Related resources from NHI Mgmt Group
- Why do phone-based recovery routes increase account takeover risk?
- Why do email and SMS recovery channels increase account takeover risk?
- Why do email accounts with weak controls increase the risk of data theft and account takeover?
- Why do email-based identity links create account takeover risk in federated login flows?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
