{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "better-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53516"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-07T20:55:13Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- Their application uses `better-auth` at a version `\u003c 1.6.11` on the stable line, or any current `next` pre-release.\n- `emailAndPassword.enabled: true` is set in their application\u0027s `betterAuth({ ... })` configuration.\n- At least one OAuth or SSO provider is configured (any built-in social provider, or `genericOAuth(...)`, or any provider via `@better-auth/sso`).\n- `account.accountLinking.disableImplicitLinking` is not set to `true`.\n- `account.accountLinking.enabled` is not set to `false`.\n\nSetting 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\u0027s row to verified, after which the password login becomes usable.\n\nFix:\n\n1. Upgrade to `better-auth@1.6.11` or later.\n2. If developers cannot upgrade, see workarounds below.\n\n### Summary\n\nThe OAuth callback\u0027s auto-link gate in `handleOAuthUserInfo` admits an implicit account link whenever the provider asserts `email_verified: true`, without requiring the local user row\u0027s `emailVerified` to also be `true`. An attacker who pre-registers a victim\u0027s email through `/sign-up/email` (which writes a row with `emailVerified: false`) can have the victim\u0027s later OAuth identity bound to the attacker\u0027s user row, granting both a password login and the victim\u0027s OAuth identity on the same account. This is the pre-account-hijacking class \u2014 the same shape as Microsoft \"nOAuth\" (2023) and the Sign in with Apple JWT flaw (2020).\n\n### Details\n\nThe auto-link gate validates only the OAuth provider\u0027s `userInfo.emailVerified` claim. The local row\u0027s `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.\n\nA separate post-link step promotes the local `emailVerified` to `true` when the provider\u0027s claim is `true` and the local email matches the provider\u0027s email. This step is correct for legitimate first-time linking, but combined with the missing local-side check it becomes load-bearing for the takeover: after the link, the attacker\u0027s password row is treated as verified, defeating `requireEmailVerification: true` as a mitigation.\n\nThe fix adds the local-side ownership check to the gate: implicit linking now also rejects when `dbUser.user.emailVerified` is `false`. The same primitive lives in `one-tap` and inherits the same fix shape; the SSO `domainVerified` short-circuit follows separately as a hardening change.\n\n### Patches\n\nFixed in `better-auth@1.6.11`. Implicit linking now refuses to attach an OAuth identity to a local account whose `emailVerified` flag is `false`. The same gate change applies in the `one-tap` sign-in plugin, which previously had its own simpler linking path. The Google ID-token `email_verified` claim is also normalized through `toBoolean` so a string `\"false\"` is treated as falsy (some Google responses send the string, which the prior code treated as truthy).\n\nThe public surface for the new gate is `account.accountLinking.requireLocalEmailVerified`, defaulted to `true`. Applications whose users sign up through OAuth without ever verifying their email locally can opt out with `account: { accountLinking: { requireLocalEmailVerified: false } }` to retain the legacy permissive behavior. The option is marked `@deprecated`; the gate at each call site carries a `FIXME` pointing at the next-minor follow-up that drops the option and makes the check unconditional.\n\nTest fixtures across the `admin`, `oidc-provider`, `mcp`, `generic-oauth`, `last-login-method`, and `oauth-provider` suites now pre-verify created users via a `databaseHooks.user.create.before` hook (or the `disableTestUser` opt-in on the oauth-provider RP fixture) so those suites continue to exercise their role and flow logic rather than tripping the new gate.\n\n### Workarounds\n\nIf developers cannot upgrade their applications immediately:\n\n- **Disable implicit linking**: set `account.accountLinking.disableImplicitLinking: true`. Forces all linking through the authenticated `/link-social` endpoint where the user must already be signed in.\n- **Disable linking entirely**: set `account.accountLinking.enabled: false`. Closes the hole but breaks the multi-login-method UX entirely.\n\n`emailAndPassword.requireEmailVerification: true` alone does not mitigate, because the link-time `emailVerified` flip promotes the attacker\u0027s row to verified.\n\n### Impact\n\n- **Account takeover via pre-account hijacking**: the attacker holds a working password login plus the victim\u0027s OAuth identity on the same account, granting persistent access.\n- **`requireEmailVerification: true` bypass**: the attacker\u0027s password login becomes usable post-link.\n- **Cross-flow reach**: every OAuth and SSO sign-in path that calls `handleOAuthUserInfo` is affected (built-in social providers, generic-oauth, oauth-proxy, SSO OIDC, SSO SAML, one-tap).\n\n### Credit\n\nReported by @avrmeduard.\n\n### Resources\n\n- [CWE-287: Improper Authentication](https://cwe.mitre.org/data/definitions/287.html)\n- [CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)\n- [Sudhodanan \u0026 Paverd, Pre-hijacked accounts: an empirical study of security failures in user account creation on the web (USENIX Security 2022)](https://www.usenix.org/conference/usenixsecurity22/presentation/sudhodanan)",
  "id": "GHSA-g38m-r43w-p2q7",
  "modified": "2026-07-07T20:55:13Z",
  "published": "2026-07-07T20:55:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-g38m-r43w-p2q7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Better Auth has an account takeover issue via OAuth auto-link to unverified pre-registered email"
}