chore(deps): update better-auth monorepo to v1.6.11

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@better-auth/api-key (source)	1.6.10 → 1.6.11
@better-auth/passkey (source)	1.6.9 → 1.6.11
better-auth (source)	1.6.10 → 1.6.11

---

Release Notes

better-auth/better-auth (@​better-auth/api-key)

v1.6.11

Compare Source

Patch Changes

• #​9505 b039985 Thanks @​Kvizas! - API key requests that exceed the configured rate limit now return HTTP 429 (Too Many Requests) instead of HTTP 401 (Unauthorized), so clients can distinguish throttling from authentication failures.

• Updated dependencies [0cbddb8, a26333b, 99a254a, ee93485, 5f09d56, b4bc65a, da7e50b, a1c9f3c, 23094a6, 142b86c, 1f2ff42, b0ef96f, 699b09a, e21d744]:

  • @​better-auth/core@​1.6.11
  • better-auth@​1.6.11

better-auth/better-auth (@​better-auth/passkey)

v1.6.11

Compare Source

Patch Changes

• Updated dependencies [0cbddb8, a26333b, 99a254a, ee93485, 5f09d56, b4bc65a, da7e50b, a1c9f3c, 23094a6, 142b86c, 1f2ff42, b0ef96f, 699b09a, e21d744]:
  • @​better-auth/core@​1.6.11
  • better-auth@​1.6.11

v1.6.10

Compare Source

Patch Changes

• #​9429 ddae581 Thanks @​cyphercodes! - Return a handled auth cancellation when passkey autofill authentication cannot start.

• Updated dependencies [1e0f26d, 8c1e917, b2d655c, 09f1327, 906b7b3, e9c978e, e71aad3, 80a655d, 15ff28a, 88a7c67, 9a7b51d, 1b25902, cf59136, a597ee0, fc02ced, 9f1ef1f, 36ef808, c1336c5, 3a9a2c3, fde0432, 2220a6d]:

  • better-auth@​1.6.10
  • @​better-auth/core@​1.6.10

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

v1.6.11

Compare Source

Patch Changes

• #​9568 0cbddb8 Thanks @​gustavovalverde! - Add internalAdapter.consumeVerificationValue(identifier): atomically consume a verification row keyed by identifier. The first concurrent caller receives the row; later racers receive null. Backed by a new DBAdapter.consumeOne primitive implemented natively per adapter (memory, mongo, drizzle, kysely, prisma), with a transaction(findMany + delete) factory fallback. SecondaryStorage.getAndDelete is added as an optional companion; Redis ships it via an atomic Lua get-and-delete operation for compatibility with Redis versions before 6.2.

• #​9162 a26333b Thanks @​ping-maxwell! - fix: cleanup sessions when admin, anonymous, or SCIM deletes a user

• #​9573 99a254a Thanks @​gustavovalverde! - fix(device-authorization): require verify-time ownership claim for approve/deny

  Pending device codes were not bound to the user who entered the code on the verification page until approval, leaving a window where any authenticated user could approve or deny another user's pending code by knowing the user_code. GET /device now claims the pending row for the calling session, and POST /device/approve and POST /device/deny require the calling session to match the claimed owner. Custom verification pages must be served to an authenticated session for the flow to succeed.

• #​8948 ee93485 Thanks @​ping-maxwell! - fix: add error code to change-email-disabled

• #​9572 5f09d56 Thanks @​gustavovalverde! - Fix race condition in the magic-link plugin's verify handler that allowed two concurrent requests to mint two sessions from the same single-use token. The handler now consumes the verification row atomically via internalAdapter.consumeVerificationValue, so a given magic link mints at most one session regardless of concurrency. The allowedAttempts option is retained for backward compatibility but no longer multiplies successful redemptions; tokens are single-use. The second-redeem error code changes from ATTEMPTS_EXCEEDED to INVALID_TOKEN (the token no longer exists after consumption).

• b4bc65a Thanks @​gustavovalverde! - Fix race condition in the OAuth authorization-code grant: two concurrent token-exchange requests sharing the same code could both pass the find step before either delete completed and each mint an independent access/refresh/id token set. The authorization_code handler in @better-auth/oauth-provider, plus the legacy oidc-provider and mcp plugins in better-auth, now consume the verification row atomically via internalAdapter.consumeVerificationValue. The first caller mints tokens; concurrent racers receive invalid_grant (RFC 6749 §5.2). Malformed-verification-value branches in @better-auth/oauth-provider previously returned a project-specific invalid_verification code; those are now invalid_grant so spec-compliant clients can branch on the standard code.

• #​9578 da7e50b Thanks @​gustavovalverde! - handleOAuthUserInfo (used by every social provider, generic-oauth, oauth-proxy, SSO OIDC and SAML, and idToken sign-in) implicitly linked a returning OAuth identity into a local user row whenever the IdP's email_verified claim was true or the provider was trusted. The local row's own emailVerified flag was read only to flip it after linking, never as a precondition. POST /sign-up/email creates rows with emailVerified: false for any caller, so an attacker who pre-registered a victim's email at the application could wait for the legitimate user's first OAuth sign-in: the IdP's verified claim was treated as ownership proof, and the victim's IdP identity was linked into the attacker-owned row.

  The implicit-link gate now requires dbUser.user.emailVerified === true in addition to the provider trust check by default. A new account.accountLinking.requireLocalEmailVerified option (default true) is the public surface for this gate. Apps whose users sign up via OAuth without verifying their email locally can opt back into the legacy behavior with account: { accountLinking: { requireLocalEmailVerified: false } }; understand the takeover risk before doing so. The option is @deprecated; a FIXME at each gate site points at the next-minor follow-up on next that drops the option and makes the gate unconditional.

  The one-tap plugin honored its own copy of the gate and was updated identically: requireLocalEmailVerified and accountLinking.disableImplicitLinking both apply on /one-tap/callback. The email_verified claim from the Google ID token is now normalized via toBoolean so a string "false" is treated as falsy.

  Test fixtures across admin, oidc-provider, mcp, generic-oauth, last-login-method, and oauth-provider suites now mark users emailVerified: true via a databaseHooks.user.create.before hook (or the disableTestUser opt-in on the oauth-provider RP) so the suites continue to exercise their role/flow logic rather than the new gate.

• #​9507 a1c9f3c Thanks @​GautamBytes! - Preserve exact access-control role statement types so predefined organization roles expose only their configured permissions in TypeScript.

• #​9577 23094a6 Thanks @​gustavovalverde! - The organization plugin's invitation recipient endpoints (acceptInvitation, rejectInvitation, getInvitation, listUserInvitations) treated invitation.email.toLowerCase() === session.user.email.toLowerCase() as proof that the calling user owned the invited address. A session-authenticated user whose email matched but was never verified passed the gate, so anyone who could pre-register an unverified account at a victim's email could accept invitations addressed to that email. The requireEmailVerificationOnInvitation opt-in option closed the gap only when explicitly enabled and did not protect getInvitation or listUserInvitations at all.

  The gate is now applied on all four recipient endpoints and the requireEmailVerificationOnInvitation option default flips from false to true so existing apps are secure by default. Apps that intentionally accept invitations from unverified accounts can keep the legacy permissive behavior with organization({ requireEmailVerificationOnInvitation: false }), but they should understand the takeover risk before doing so. Server-side calls to listUserInvitations with ctx.query.email and no session continue to bypass the gate (the caller is trusted).

  The option is @deprecated. The next-minor release on next removes it entirely and makes the gate unconditional.

• #​9548 142b86c Thanks @​dipan-ck! - anonymous plugin now correctly calls onLinkAccount when email verification triggers auto sign-in

• #​9576 1f2ff42 Thanks @​gustavovalverde! - fix(oidc-provider, mcp): authenticate confidential clients on refresh_token grant and harden secret comparison

  Refresh-token grants on the legacy oidc-provider and mcp plugins now require the registered client_secret from confidential clients, matching the authorization_code path. Public clients (where code_verifier substitutes for the secret on the auth-code grant) continue to skip secret validation. Secret comparisons across both plugins now use constant-time equality. The /mcp/token endpoint no longer emits a wildcard CORS Access-Control-Allow-Origin: * header.

  These plugins are deprecated in favor of @better-auth/oauth-provider, which is unaffected. New deployments should adopt the replacement; this patch keeps existing deployments protected while migrating.

• #​9575 699b09a Thanks @​gustavovalverde! - fix(oidc-provider, mcp): drop "none" from advertised signing algorithms, default allowPlainCodeChallengeMethod to false, and reject missing PKCE method

  The legacy oidc-provider and mcp plugins now follow OAuth 2.1 (RFC 9700) on three protocol gates:

  • id_token_signing_alg_values_supported (oidc-provider, mcp) and resource_signing_alg_values_supported (mcp) no longer include "none". Relying parties that negotiate from this list will no longer be steered toward unsigned tokens.
  • allowPlainCodeChallengeMethod defaults to false. Callers who need plain PKCE must opt in explicitly.
  • Under the secure default the authorize endpoint no longer silently rewrites a missing code_challenge_method to "plain" before the allowlist check. A request that provides code_challenge without code_challenge_method is now rejected with invalid_request; the inverse case (code_challenge_method without code_challenge) is also rejected so no inconsistent PKCE state is persisted on the authorization code record.

  Non-breaking for callers who never relied on "none" advertisement or the plain default. Callers who explicitly set allowPlainCodeChallengeMethod: true keep plain on the allowlist and retain the legacy "missing method defaults to plain" behavior for backward compatibility, so existing integrations that opted into plain PKCE continue to work. The next-minor on next will drop both the plain allowlist entry and this fallback; until then, the option is the single explicit knob for legacy behavior. Migrate to @better-auth/oauth-provider for the canonical, spec-aligned implementation.

• Updated dependencies [0cbddb8, c6918ec, da7e50b, b0ef96f, e21d744]:

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

---

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 these updates again.

---

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

---

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

[safedep]

SafeDep Report Summary

Package Details

Package	Malware	Vulnerability	Risky License	Report
@better-auth/api-key @ 1.6.11 pnpm-lock.yaml				🔗
@better-auth/core @ 1.6.11 pnpm-lock.yaml				🔗
@better-auth/drizzle-adapter @ 1.6.11 pnpm-lock.yaml				🔗
@better-auth/kysely-adapter @ 1.6.11 pnpm-lock.yaml				🔗
@better-auth/memory-adapter @ 1.6.11 pnpm-lock.yaml				🔗
@better-auth/mongo-adapter @ 1.6.11 pnpm-lock.yaml				🔗
@better-auth/passkey @ 1.6.11 pnpm-lock.yaml				🔗
@better-auth/prisma-adapter @ 1.6.11 pnpm-lock.yaml				🔗
@better-auth/telemetry @ 1.6.11 pnpm-lock.yaml				🔗
better-auth @ 1.6.11 pnpm-lock.yaml				🔗

View complete scan results →

_{This report is generated by SafeDep Github App}