CVE-2026-53516: 
Better Auth vulnerability analysis and mitigation

CVE-2026-53516 is a pre-account hijacking vulnerability in Better Auth, a TypeScript authentication and authorization library, classified as an nOAuth-class implicit OAuth account linking flaw. It affects all versions of better-auth prior to 1.6.11 for Node.js. The vulnerability was first published on May 31, 2026 (privately), added to the GitHub Advisory Database on July 7, 2026, and published by NVD on July 15, 2026. It carries a CVSS v3.1 base score of 8.3 (High) (Github Advisory, Security Advisory).

The root cause (CWE-287: Improper Authentication; CWE-345: Insufficient Verification of Data Authenticity) lies in the handleOAuthUserInfo function's implicit account-linking gate, which validates only the OAuth provider's email_verified claim without checking whether the local database user row's emailVerified field is also true. When no (accountId, providerId) match exists, the lookup falls back to email address, surfacing any pre-registered row — including attacker-created ones with emailVerified: false. A post-link step then promotes the local emailVerified to true based on the provider's claim, which inadvertently makes the attacker's password-based login usable and defeats emailAndPassword.requireEmailVerification: true as a mitigation. The same flaw exists in the one-tap sign-in plugin, and a secondary issue was identified where Google ID-token email_verified string "false" was incorrectly treated as truthy. The attack requires no privileges but does require the victim to perform an OAuth sign-in action (Security Advisory, Fix PR).

Successful exploitation results in full account takeover: the attacker gains a working password login and the victim's OAuth identity on the same account, granting persistent access to all victim data and application functionality. Every OAuth and SSO sign-in path that calls handleOAuthUserInfo is affected, including built-in social providers (Google, GitHub, etc.), generic-oauth, oauth-proxy, SSO OIDC, SSO SAML, and one-tap. The requireEmailVerification: true configuration bypass means that even applications that believed they had enforced email verification are vulnerable, and the attacker's account is silently promoted to verified status post-exploitation (Github Advisory, Security Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation as of the time of publication (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.152% (0.00236 per Feedly data), placing it in the 5th percentile for exploitation likelihood. The attack is not automatable (per NVD SSVC assessment) as it requires the victim to initiate an OAuth sign-in, but the attacker's setup step (pre-registering the victim's email) requires no privileges and can be performed against any application with emailAndPassword.enabled: true and at least one OAuth provider configured (Github Advisory).

1. Reconnaissance: Identify a target application using Better Auth < 1.6.11 with both emailAndPassword.enabled: true and at least one OAuth/SSO provider configured, and where account.accountLinking.disableImplicitLinking is not set to true.
2. Pre-register victim email: Using the application's /sign-up/email endpoint, register an account with the victim's known email address and an attacker-chosen password. This creates a local user row with emailVerified: false.
3. Wait for victim OAuth sign-in: The attacker waits for the legitimate victim to sign in via an OAuth provider (e.g., Google, GitHub) using their email address. This is a social engineering or opportunistic step.
4. Implicit account linking triggered: When the victim authenticates via OAuth, the provider asserts email_verified: true. Better Auth's handleOAuthUserInfo looks up the local user by email, finds the attacker's pre-registered row, and — because it only checks the provider's claim and not the local emailVerified field — implicitly links the victim's OAuth identity to the attacker's account.
5. Post-link promotion: The post-link step promotes the attacker's local row's emailVerified to true, making the attacker's password login fully usable.
6. Account access: The attacker logs in using the pre-registered email and password, now authenticated as the victim with full access to their account data and session (Security Advisory, Fix PR).

• Logs: Unexpected account creation (POST /sign-up/email) for an email address that belongs to a known user, followed later by an OAuth callback (GET /callback/<provider>) for the same email — especially if the OAuth callback does not result in a new user creation but instead links to an existing row.
• Database: User rows where emailVerified transitions from false to true coinciding with an OAuth callback event, without a corresponding email verification token redemption event.
• Database: Account rows where a new OAuth providerId/accountId pair is linked to a user whose emailVerified was previously false, particularly if the user also has a password-based credential.
• Application Behavior: Victim reports being unable to access their account, or reports unexpected activity — indicating the attacker has taken over the account after the victim's OAuth sign-in triggered the implicit link (Security Advisory).

The primary remediation is to upgrade to better-auth@1.6.11 or later, which adds a local emailVerified precondition to the implicit linking gate in handleOAuthUserInfo and the one-tap plugin via the new account.accountLinking.requireLocalEmailVerified option (defaulted to true) (v1.6.11 Release, Fix Commit). If an immediate upgrade is not possible, two workarounds are available: (1) set account.accountLinking.disableImplicitLinking: true to force all linking through the authenticated /link-social endpoint, or (2) set account.accountLinking.enabled: false to disable linking entirely (at the cost of multi-login-method UX). Note that emailAndPassword.requireEmailVerification: true alone does not mitigate this vulnerability (Github Advisory).

The vulnerability was reported by security researcher @avrmeduard and is categorized as an nOAuth-class pre-account hijacking flaw, analogous to the Microsoft "nOAuth" vulnerability (2023) and the Sign in with Apple JWT flaw (2020), as noted in the official advisory (Security Advisory). The Better Auth maintainers responded promptly, merging the fix on May 12, 2026, and releasing version 1.6.11 the same day. The advisory references the academic work by Sudhodanan & Paverd on pre-hijacked accounts (USENIX Security 2022), situating this vulnerability within a well-documented class of authentication library flaws.