BETTER-AUTH · GHSA-fvxx-76fc-893x · Package
FIX → 1.8.0-beta.5 +1
Sessions revoked in better-auth can keep working when secondary storage is used or when the session cookie cache is on, and some routes accept a cached session to create new lasting credentials. An attacker who already holds a valid session for an account can keep access after it is revoked, but cannot get in without credentials.
first public Nov 3, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications that use better-auth with secondaryStorage (from 0.8.1-beta.5) or with session.cookieCache plus passkey registration, device authorization, or passwordless two-factor enrollment (from 1.6.25). Apps without secondary storage and without the cookie cache enabled are not exposed to the revocation gap, and the attacker must already hold a valid session.
Not affected if auth-required, cookie-cache-off, no-secondary-storage
Who cares @better-auth/passkey, better-auth, node, typescript
npm ls better-auth @better-auth/passkey.secondaryStorage and .You are affected if you use better-auth with any of these:
secondaryStorage, from 0.8.1-beta.5.session.cookieCache with passkey registration, device authorization, or passwordless two-factor enrollment, from 1.6.25.Bulk revocation. With secondary storage, two session changes at the same time could drop a session from the user's session list. Revoking all sessions or banning the user then missed it.
Cached sessions. With the cookie cache, a revoked session keeps working until the cache maxAge ends, which is documented. Some features accepted that cached session to create a passkey or a new stored session that outlived the cache.
Both problems need an attacker who already holds a valid session for the account. They let that attacker keep access after the session is revoked. Neither problem gives access to an account without credentials.
Upgrade better-auth and @better-auth/passkey to 1.7.16, or to 1.8.0-beta.5 on the beta line.
Passkey registration, device authorization, two-factor enrollment and verification, social account linking, and phone number changes now check the session store, even with the cookie cache on. On 1.7.16, sessions created from API keys are refused on these routes, except two-factor enrollment and phone number changes. On 1.8.0-beta.5, they are refused on all of them.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
cookieCacheUpgrade to 1.8.0-beta.5 +1
better-auth 1.7.16 (from >= 0.8.1-beta.5, < 1.7.16), or 1.8.0-beta.5 on the beta line (from >= 1.8.0-beta.0, < 1.8.0-beta.5).@better-auth/passkey 1.7.16 (from >= 1.6.25, < 1.7.16), or 1.8.0-beta.5 on the beta line.session.cookieCache if revocation must be immediate, and stop using secondaryStorage for bulk revocation.Turn off session.cookieCache if revocation must take effect immediately. For bulk revocation, stop using secondaryStorage until you upgrade.
The secondary storage session list is updated by reading and writing it in two steps, so concurrent writers could drop a token. Bulk revocation now also records a cutoff time, and sessions created before it count as revoked even when the list missed them. The affected routes now read the session from the store instead of the cookie cache before creating a lasting credential or session.