GHSA-g38m-r43w-p2q7: Better Auth has an account takeover issue via OAuth auto-link to unverified pre-registered email

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 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 promotes the local emailVerified to true when the provider's claim