better-auth EUVD-2026-51828

All three of the following conditions must hold simultaneously for the vulnerability to be exploitable: (1) secondaryStorage must be configured on the betterAuth() initialization - for example, a Redis adapter or Cloudflare KV; (2) session.storeSessionInDatabase must be false or unset, which is the library default; and (3) user deletion must be triggered through one of the four affected endpoints - the admin plugin's removeUser API, the anonymous plugin's /delete-anonymous-user endpoint or its after-link hook, or the SCIM plugin's DELETE /scim/v2/Users/:userId route. Deployments using only the core /delete-user self-delete flow are NOT vulnerable. Exploitation of the lingering session itself requires only possession of a valid session token that was issued before deletion - no current account credentials or elevated privileges are needed at that point. The combination of a non-default external cache configuration and specific deletion endpoint routing limits the realistic exposure population.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:H) scores 5.1 and reflects that high privileges are needed to trigger the vulnerable deletion operation. However, the operational risk picture is more nuanced: the actor who exploits the lingering session is not necessarily the admin who performed the deletion - it is whoever possesses the old session token, which could be a terminated employee, an attacker who previously compromised the account, or a shared-session scenario. From that angle, the exploitation step itself requires no current privileges. Real-world risk is meaningfully gated by the required configuration intersection: secondaryStorage must be in use AND storeSessionInDatabase must be false (the default) AND deletion must route through one of the four affected endpoints. Deployments using only database-backed sessions are entirely unaffected. No EPSS data was provided in the input. No KEV listing and no POC are reported, suggesting low active exploitation pressure at time of analysis. For organizations running Redis-backed better-auth with admin or SCIM user management, however, the risk of access persistence after offboarding is concrete and should be treated as a priority.

A company terminates an employee and an administrator uses the better-auth admin plugin to call removeUser. Because the deployment uses Redis as secondaryStorage with the default storeSessionInDatabase=false, the employee's existing session token is never evicted from Redis. The former employee, still in possession of their session cookie, continues to make authenticated API requests for up to seven days, potentially accessing sensitive data or performing write operations under their former identity. No public exploit code has been identified at time of analysis.