Upgrading to 0.14
0.14 raises the minimum peer versions for security fixes, and needs a cleanup if you applied the 0.11 account issuer migration.
0.14.0 raises the minimum peer versions, for security fixes only. The plugin's own behavior is unchanged; there is no API change.
If you cannot upgrade a peer yet, stay on 0.13.2 and apply the upstream workarounds listed in the CHANGELOG.
New peer floors
| Peer | Floor | Why |
|---|---|---|
better-auth, @better-auth/api-key, @better-auth/passkey | >=1.7.7 | Critical Magic Link account takeover (GHSA-965c-763c-88jm) and an OAuth Proxy account takeover (GHSA-r4xp-prcw-77qf). |
next | >=16.4.1 <17 | Two critical remote code executions and a Server Actions denial of service. Next 15 is dropped. |
payload, @payloadcms/next, @payloadcms/ui | >=3.90.0 | The October batch of Payload advisories, several in auth collections and API keys. |
| Node | >=22.23.4 | Node 20 is end-of-life and did not receive the October 2026 security releases. |
After upgrading Better Auth, request fresh magic links and restart pending OAuth/SAML flows, as the advisory requires. Better Auth 1.7.12 is recommended.
Account issuer cleanup
Only if you applied the 0.11 issuer migration
Better Auth 1.7.3 reverted the issuer account schema. Accounts are keyed on (providerId, accountId) again, new rows no longer write issuer, and the generated accounts collection no longer emits the field or its unique index. If you applied the 0.11 migration, relax it before upgrading past Better Auth 1.7.2, or every sign-up and account link fails on the NOT NULL constraint.
ALTER TABLE accounts ALTER COLUMN issuer DROP NOT NULL;
DROP INDEX accounts_issuer_account_id_idx; -- use the name Payload generated; drop the index before any column drop on MySQLpayload migrate:create then proposes dropping the issuer column and its index. Applying it is the full cleanup. See the Better Auth upgrade guide.
0.14.1 and 0.14.2
- 0.14.1: the
jwtplugin works at its defaults. The adapter had queriedjwksswhile the generated collection isjwks. If you worked around it withschema: { jwks: { modelName: 'jwk' } }, that still works and can be removed. If you hand-registered ajwksscollection, rename its slug tojwks. - 0.14.2: on Postgres,
incrementOneandconsumeOneuse one guarded SQL statement. No migration is required. See Atomic operations.