Better Auth’s November fixes: check revoked sessions and Stripe ownership

If your app uses Better Auth for login or its Stripe plugin for subscriptions, review the November security release and update the packages your app actually uses. Then check two things separately: whether revoked sessions lose access, and whether existing billing records point to the correct customer. A dependency update is only one part of that work. Better Auth’s release notice.

This guide focuses on those two application workflows. It provides an editorial verification plan using disposable accounts and synthetic billing records; VAS has not tested your application or reproduced these vulnerabilities.

Establish which packages and features you use

The notice originally dated October 30 now describes fixes released November 3: Better Auth 1.7.16 and 1.8.0-beta.5 address 12 advisories. The vendor asks developers to update separately released Better Auth plugins together and read their configuration requirements. These were the original fix versions. Release notice and advisory index.

The current changelog, checked November 10, lists 1.7.20 as latest, with additional releases after 1.7.16. Choose current compatible packages on your supported release line; do not move a stable application onto beta merely because a beta fix is listed. Recheck available package versions before making the change. Current changelog.

Ask the person maintaining your app to record:

• The resolved better-auth version in the deployed build, plus installed plugins and adapters.
• Whether session handling uses secondaryStorage, session.cookieCache, or custom session hooks.
• Whether passkeys, device authorization or passwordless two-factor enrollment are enabled.
• Whether @better-auth/stripe is registered, subscriptions are enabled, and billing belongs to users, organizations or both.

Review the full advisory index for every enabled feature. This article’s two checks cannot close the other advisories. If an AI coding assistant helps with the inventory, give it configuration structure with secrets removed. Ask for file locations and resolved package versions, then review the proposed changes yourself.

Workstream one: prove that revocation ends the intended access

The session advisory covers specific storage and cache configurations. Its original patched versions are 1.7.16 and 1.8.0-beta.5; it lists affected better-auth versions beginning at 0.8.1-beta.5, and affected passkey versions beginning at 1.6.25, below the corresponding fixes. Check both the version ranges and the feature conditions. Session advisory.

According to the maintainers, concurrent session-list updates in secondary storage could leave a session out of bulk revocation. Cookie caching has a documented delay before revoked sessions expire, but some features could turn cached access into a longer-lived credential or session. Both problems require an attacker who already has a valid session. They do not independently provide access without credentials. Scope and prerequisites.

There is a follow-up worth including in your upgrade review: version 1.7.18 addresses sessions created during bulk revocation when using secondaryStorage with storeSessionInDatabase. The changelog explicitly says sessions created by a session.delete.after hook remain active. If your app creates sessions in that hook, document whether that behavior meets your security requirement. November 5 follow-up.

Write an acceptance rule before testing

Use an isolated staging environment with your actual session-storage configuration and disposable accounts. Define the control being tested: signing out one browser, revoking all sessions, and banning an account are different actions. A single-browser sign-out test cannot establish that bulk revocation works.

For each control, name a harmless server operation that requires the account’s authority, such as reading a synthetic private note. Use that operation to test access. A sign-in screen or a missing avatar alone is weak evidence because it checks presentation rather than the protected operation.

This is a suggested acceptance matrix, not a vendor reproduction or a test VAS has run:

Sensitive enrollment needs its own check. The advisory says patched routes consult the session store for operations including passkey registration, device authorization and two-factor enrollment, even when cookie caching is enabled. Verify applicable flows using the revoked disposable session. Sensitive-route changes.

If immediate revocation is a requirement, the maintainer’s workaround is to disable session.cookieCache; for vulnerable bulk-revocation handling, it says to stop using secondaryStorage until upgraded. Treat either configuration change as an application change requiring rollout and validation, rather than running a blanket cache-deletion command. Maintainer workarounds.

Keep tokens and cookie values out of test reports. Record account aliases, timestamps, build identifiers and pass/fail outcomes. A passing controlled run supports the tested behavior; it does not prove every possible race is absent.

Workstream two: separate billing ownership repair from the upgrade

The Stripe advisory affects registered @better-auth/stripe plugins from 1.2.0-beta.18 below 1.7.16, and the 1.8 beta line before beta.5. The billing effects require subscription.enabled: true. A signed-in user who knows another customer’s Stripe ID could target that customer’s billing portal. The maintainers distinguish this from signing in as the other user or exposing Stripe API keys. Stripe advisory.

The fix blocks customer IDs and plugin-managed subscription fields from sign-up and update-user input, including auth.api.updateUser. Legitimate server code that previously set those fields through that API must use the database adapter instead. The upgrade does not change previously written values. The vendor calls for duplicate customer-ID checks, comparison with Stripe customer metadata.userId, and equivalent organization checks where applicable. Write boundary and recovery guidance.

Give historical reconciliation an authorized owner

Have an operator with approved access review the ownership relationships. Preserve a restricted snapshot before corrections, record schema customizations, and use the advisory’s checks as a starting point. Never paste customer exports, payment information or full identifiers into an assistant prompt or public issue.

For a synthetic example, suppose app records account_amber and account_birch both point to customer_demo_17. That duplicate is a question to resolve, not permission to delete either account. Determine the intended owner from authoritative records. If metadata is missing or disagrees with the application, keep the case open for investigation.

Use a restricted reconciliation worksheet with separate fields for:

1. The application owner and whether it is a user or organization.
2. The customer identifier, represented by an internal alias in shared reports.
3. The authoritative evidence supporting the relationship.
4. Any dependent subscription or entitlement records requiring review.
5. The approved correction, operator, time and verification result.

A duplicate-ID search is a useful filter, not a complete historical assessment. Review how customer IDs were created and changed, how much history is available, and which records your checks actually covered. Escalate confirmed unauthorized billing activity through your incident process. Do not describe an empty duplicate report as proof that misuse never happened.

Verify billing boundaries with disposable records

In staging with Stripe test-mode resources, create two disposable app accounts with distinct intended customers. Verify that each account’s normal billing entry point resolves to its own test customer. Review sign-up and profile-update handling to ensure customer ownership is chosen by authorized server logic.

Check legitimate administrative writes too. Replacing a rejected updateUser call with an unrestricted adapter write would move the ownership problem into your application code. Require the server operation to establish who may change the relationship and why; keep that decision out of browser-supplied profile fields.

For webhook verification, trace a synthetic event through the application’s intended owner mapping and record the resulting test entitlement. Use test-mode data throughout. Never validate a fix by opening another real customer’s portal, altering a live subscription or testing against an affected third-party app.

Keep one closure record for the deployed application

Assign separate owners to package deployment, session verification and billing reconciliation. Retain the resolved dependency versions, deployment identifier, relevant configuration choices, synthetic test outcomes and unresolved historical cases. Check every environment that serves authentication or billing requests.

A completed installation, a successful login and a billing portal that opens are different observations. Close each workstream only when its intended authority boundary has been checked. Keep any unreviewed plugin advisory visible rather than treating this guide as a certificate for the whole application.

The primary sources establish affected behavior and maintainer fixes. They do not establish whether your application was exploited. VAS has not inspected customer records, tested these packages or independently validated the vendor’s implementation. Recheck the release notice, current changelog, session advisory and Stripe advisory before deploying or publishing guidance.