CVE-2026-53516

### 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 `[email protected]` 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 the victim's OAuth identity on the same account. This is the pre-account-hijacking class — the same shape as Microsoft "nOAuth" (2023) and the Sign in with Apple JWT flaw (2020). ### Details The auto-link gate validates only the OAuth provider's `userInfo.emailVerified` claim. The local row's `emailVerified` field is never read. When no `(accountId, providerId)` match exists, the user lookup falls back to email, which surfaces any pre-registered row at that email. A separate post-link step prom