Better Auth is an authentication and authorization library for TypeScript. Prior to 1.6.11, Better Auth's OAuth callback auto-link gate in handleOAuthUserInfo accepts implicit account linking when the OAuth provider asserts email_verified: true without requiring the local user row's emailVerified field to also be true, allowing an attacker who pre-registers a victim email through /sign-up/email to bind the victim's OAuth identity to the attacker's account. The same primitive affects one-tap, and emailAndPassword.requireEmailVerification: true does not mitigate the link-time verification change. This issue is fixed in version 1.6.11.

Affected: npm: better-auth

### Am I affected?

Users are affected if all of the following are true:

- Their application uses `better-auth` at a version `< 1.6.11` on the stable line, or any current `next` pre-release. - `emailAndPassword.enabled: true` is set in their application's `betterAuth({ ... })` configuration. - At least one OAuth or SSO provider is configured (any built-in social provider, or `genericOAuth(...)`, or any provider via `@better-auth/sso`). - `account.accountLinking.disableImplicitLinking` is not set to `true`. - `account.accountLinking.enabled` is not set to `false`.

Setting either `disableImplicitLinking: true` or `enabled: false` closes the hole at the cost of breaking the standard "add another login method" UX. `emailAndPassword.requireEmailVerification: true` does not mitigate, because the link-time `emailVerified` flip promotes the attacker's row to verified, after which the password login becomes usable.

Fix:

1. Upgrade to `better-auth@1.6.11` or later. 2. If developers cannot upgrade, see workarounds below.

### Summary

The OAuth callback's auto-link gate in `handleOAuthUserInfo` admits an implicit account link whenever the provider asserts `email_verified: true`, without requiring the local user row's `emailVerified` to also be `true`. An attacker who pre-registers a victim's email through `/sign-up/email` (which writes a row with `emailVerified: false`) can have the victim's later OAuth identity bound to the attacker's user row, granting both a password login and t…