chore(deps): update dependency better-auth to v1.6.22 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
better-auth (source)	1.6.20 → 1.6.22

---

Better Auth: Account takeover via pre-account hijacking on magic-link and email-OTP sign-in

GHSA-qq9h-g4jm-xgf3

More information

Details

Am I affected

You are affected if all of the following hold:

• You run a better-auth version below 1.6.22, or a 1.7.0-beta below 1.7.0-beta.10.
• You enable the magic-link plugin or the email-OTP plugin.
• You also enable email and password sign-up with open registration.
• An account can exist at an address before its owner first signs in with the passwordless flow.

Summary

An attacker can keep password access to a victim's account after the victim starts using it. The attack runs in three steps. First, with open registration, the attacker signs up using the victim's email and a password the attacker picks. The account stays unverified, so the attacker cannot use it yet. Later the real owner signs in with a magic link or an email OTP. That step marks the account verified, and the attacker's password now works on it.

Details

When an account already exists for an address, magic-link verification and email-OTP sign-in both sign in to that account. They mark it verified and issue a session. Before the fix, neither one removed a password set while the account was still unverified. Neither one revoked existing sessions. So a password set before anyone proved control of the mailbox kept working after the owner proved control.

This is a pre-account-hijacking weakness. It is the same class as the OAuth advisory GHSA-g38m-r43w-p2q7, applied to the passwordless email flows. Requiring email verification does not stop it. The verification step is the exact moment that turns the planted account into a usable one.

The fix treats current proof of control over the address as authoritative. When either flow finds an account whose email was never confirmed, it now removes the password and revokes existing sessions first. Only then does it mark the account verified and issue the new session. The owner signs in as before. Only access created before the proof is removed.

Patches

Upgrade to better-auth 1.6.22 or later on the stable line. On the 1.7 pre-release line, upgrade to 1.7.0-beta.10 or later. Earlier 1.7 betas, up to and including 1.7.0-beta.9, still contain the bug.

Workarounds

If you cannot upgrade right away, you can lower the risk in two ways. Require email verification before you accept any password on an account. Remove unverified accounts quickly, so an address cannot sit reserved for long. Both steps shrink the opening, but they do not close it. Upgrading is the real fix.

Impact

The attacker gains lasting password access to an account the victim depends on, alongside the victim. From there the attacker can read and change the victim's data. The attacker can also reset the credentials and lock the victim out. The takeover only completes when the victim signs in through the passwordless flow. It also needs a setup that pairs that flow with open email and password sign-up.

Credit

Reported by the Vercel security team.

Severity

• CVSS Score: 8.3 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L

References

• https://github.com/better-auth/better-auth/security/advisories/GHSA-qq9h-g4jm-xgf3
• https://github.com/better-auth/better-auth/pull/10239
• https://github.com/better-auth/better-auth/commit/c06a56d83a40bbaeac12d3a8b8b67e59f92a9110
• https://github.com/better-auth/better-auth/releases/tag/v1.6.22
• https://github.com/better-auth/better-auth/releases/tag/v1.7.0-beta.10
• https://github.com/advisories/GHSA-qq9h-g4jm-xgf3

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

better-auth/better-auth (better-auth)

v1.6.22

Compare Source

Patch Changes

• #​10239 c06a56d Thanks @​gustavovalverde! - Magic-link and email-OTP sign-in now reset the credentials on an account whose email had never been confirmed. When verification resolves to such an account, any existing password on it is removed and its sessions are revoked before the user is signed in, so proven control of the mailbox is the source of truth for the account.

  If you signed up with email and password but first signed in through a magic link or email OTP rather than confirming the verification email, your password is cleared and you will need to set a new one through password reset.

• #​10240 3a035e9 Thanks @​gustavovalverde! - Add account-level lockout for two-factor verification. The attempt limit applies per account across sign-in challenges and across factors: TOTP, email-OTP, and backup codes share one counter, and a successful verification resets it.

  Enabled by default: an account locks for 15 minutes after 10 consecutive failed verifications, and locked attempts return 429 with the ACCOUNT_TEMPORARILY_LOCKED error code. Configure it with twoFactor({ accountLockout: { enabled, maxFailedAttempts, durationSeconds } }).

  Run a database migration after upgrading: this adds failedVerificationCount and lockedUntil columns to the twoFactor table.

• Updated dependencies [8bd43d9]:

  • @​better-auth/core@​1.6.22
  • @​better-auth/drizzle-adapter@​1.6.22
  • @​better-auth/kysely-adapter@​1.6.22
  • @​better-auth/memory-adapter@​1.6.22
  • @​better-auth/mongo-adapter@​1.6.22
  • @​better-auth/prisma-adapter@​1.6.22
  • @​better-auth/telemetry@​1.6.22

v1.6.21

Compare Source

Patch Changes

• #​10212 e0762a1 Thanks @​bytaesu! - In root-mounted deployments, requests whose path does not start with the configured basePath now return 404 instead of resolving to an endpoint.

• #​10187 882cf9e Thanks @​ping-maxwell! - Admin permission changes and bans now take effect immediately for admin APIs, even when session cookie cache is enabled. Sensitive session checks also continue to work in stateless apps where signed cookies are the session record.

• #​9939 f52e1ab Thanks @​benpsnyder! - fixes a bug causing deviceAuthorization() throwing a ZodError at construction when called without a schema option

• #​10196 b5bec19 Thanks @​Paola3stefania! - OAuth sign-up and account-link profile sync now ignore provider profile values for user fields marked input: false. Input-allowed additional fields still persist from mapProfileToUser, and schema defaults still apply when OAuth creates a user. Apps that used mapProfileToUser to fill input: false fields should set those fields in server-side provisioning code instead.

• #​10197 816d7f9 Thanks @​Paola3stefania! - Google sign-in now accepts hd: "*" to allow any Google Workspace hosted domain while still rejecting tokens with no hosted-domain claim.

  Google One Tap now applies the configured Google hosted-domain restriction before creating a session.

• #​10192 239bcc8 Thanks @​bytaesu! - Validate PayPal user info against the verified ID token subject during social sign-in.

• #​10228 1bc370a Thanks @​gustavovalverde! - The SIWE plugin no longer binds a provided email that already belongs to another account. With anonymous set to false, /siwe/verify previously created the new account using that email even when it was already in use; it now keeps the wallet-derived address in that case, so one email cannot be attached to two accounts.

• #​10198 570267c Thanks @​rachit367! - Honor disableMigration on plugin schema tables. Tables flagged with disableMigration: true are now skipped by better-auth generate (Drizzle and Prisma output) and by the runtime migrator, instead of being emitted and created anyway. The flag was previously dropped while assembling the table list, so it had no effect.

• #​10182 461ca6f Thanks @​bytaesu! - Only store display username fallbacks as usernames when they pass username validation during email sign-up.

• #​10183 88409b0 Thanks @​bytaesu! - Require OAuth proxy profile callbacks to match an issued OAuth state before creating sessions.

• #​10203 5953157 Thanks @​bytaesu! - Rate limiting no longer trusts multi-hop X-Forwarded-For chains, preventing a client behind an appending proxy from spoofing the leftmost hop to bypass the per-IP rate limit. Single-value IP headers continue to work. To key the real client behind a proxy chain, set advanced.ipAddress.trustedProxies to your reverse-proxy IPs or CIDR ranges (the chain is walked right to left, skipping trusted hops), or point advanced.ipAddress.ipAddressHeaders at a single trusted client-IP header.

• #​10191 b046f9e Thanks @​bytaesu! - Rate limit client requests before plugin request handlers run.

• #​10210 ae647b4 Thanks @​gustavovalverde! - Two-factor verification now locks out after five wrong codes per sign-in challenge for TOTP and backup codes. Once the limit is reached the challenge is rejected with TOO_MANY_ATTEMPTS_REQUEST_NEW_CODE, and a new sign-in is required to try again.

  During a rolling deploy, two-factor challenges issued by the previous version may prompt the user to sign in again; this clears once the deploy completes.

• Updated dependencies [90d509e, 816d7f9, 570267c, 5953157]:

  • @​better-auth/core@​1.6.21
  • @​better-auth/kysely-adapter@​1.6.21
  • @​better-auth/prisma-adapter@​1.6.21
  • @​better-auth/drizzle-adapter@​1.6.21
  • @​better-auth/memory-adapter@​1.6.21
  • @​better-auth/mongo-adapter@​1.6.21
  • @​better-auth/telemetry@​1.6.21

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.