When better-auth is configured with secondaryStorage (e.g., Redis) and session.storeSessionInDatabase is false (default), user deletion endpoints in admin, anonymous, and SCIM plugins fail to delete user sessions before deleting the user record. As a result, session payloads cached in secondary storage remain valid until their TTL expires, allowing deleted users to authenticate during that window. The vulnerability affects versions >=0.3.4 <1.6.11 and >=1.6.0 <1.6.11. The fix involves modifying these endpoints to call deleteSessions(userId) before deleteUser(userId). Workarounds include enabling session storage in the database or explicitly revoking sessions via API calls. This vulnerability corresponds to CWE-459, CWE-613, and CWE-672.

Deleted users retain valid sessions in external caches for up to the session TTL (default 7 days), allowing continued access to resources with their previous permissions. This undermines user deprovisioning, especially in SCIM-driven offboarding scenarios, where active sessions are not revoked immediately. No known exploits have been reported in the wild. The severity is low due to the requirement of authenticated privileges to delete users and the limited window of session persistence.

A fix is available in patched versions of better-auth and @better-auth/scim that ensure sessions are deleted before user records. Users should upgrade to these patched versions as soon as possible. If immediate upgrade is not feasible, workarounds include setting session.storeSessionInDatabase to true to leverage database cascades for session deletion, or explicitly revoking user sessions via API calls (auth.api.revokeUserSessions) in admin, SCIM, and anonymous user deletion flows. These mitigations eliminate the stale session persistence gap.