GHSA-2VG6-77G8-24MP

GHSA-2VG6-77G8-24MP is a low-severity security vulnerability in better-auth (npm), affecting versions >= 0.3.4, < 1.6.11. It is fixed in 1.6.11.

Summary

Better Auth: Stale sessions persist after user deletion across admin, anonymous, and SCIM flows

Full technical description

Am I affected?

Users are affected if all of the following are true:

  • They configure secondaryStorage on betterAuth(...) (Redis, KV, or any external session cache).
  • session.storeSessionInDatabase is left unset or set to false (the default).
  • Their application's deployment uses one or more of:
    • The admin plugin and calls auth.api.removeUser(...) or authClient.admin.removeUser(...).
    • The anonymous plugin and exposes /delete-anonymous-user or relies on the after-link hook to clean up the anonymous user.
    • The @better-auth/scim plugin and exposes DELETE /scim/v2/Users/:userId.

If storeSessionInDatabase is true, sessions are also written to the database, and the database delete cascades; users are not affected.

Fix:

  1. Upgrade to better-auth@<patched-version> or later (and @better-auth/scim@<patched-version> if they use SCIM).
  2. If they cannot upgrade, see workarounds below.

When secondaryStorage is configured and storeSessionInDatabase is false, three user-deletion endpoints in better-auth plus one in @better-auth/scim call internalAdapter.deleteUser(userId) without first calling internalAdapter.deleteSessions(userId). The deleted user's session payload (which carries a cached user object) remains in secondary storage, and internalAdapter.findSession(token) keeps returning it as a valid session until the session TTL elapses (default 7 days).

Details

The vulnerable call sites are:

  • admin plugin's removeUser (packages/better-auth/src/plugins/admin/routes.ts:1463).
  • anonymous plugin's self-delete endpoint (packages/better-auth/src/plugins/anonymous/index.ts:222).
  • anonymous plugin's after-link hook (packages/better-auth/src/plugins/anonymous/index.ts:325).
  • @better-auth/scim's DELETE /scim/v2/Users/:userId (packages/scim/src/routes.ts:1019).

Working callers that already do the right thing: the core /delete-user self-delete and /delete-user/callback (packages/better-auth/src/api/routes/update-user.ts:551).

The fix shape extends each vulnerable caller to invoke deleteSessions(userId) before deleteUser(userId). The architectural follow-up centralizes the cleanup inside deleteUser itself or introduces a single deleteUserAndSessions orchestrator so future callers cannot regress this contract.

Workarounds

If users cannot upgrade immediately:

  • Configuration-level: set session.storeSessionInDatabase: true. Subsequent user-delete writes reach the session table and the database cascade removes rows. Increases write volume for high-throughput sessions but eliminates the gap.
  • Code-level (admin path): when calling auth.api.removeUser, also call auth.api.revokeUserSessions({ body: { userId } }), which uses deleteSessions internally.
  • Code-level (SCIM path): wrap their SCIM provider's deprovisioning hook to call auth.api.revokeUserSessions(...) after the SCIM DELETE.
  • Code-level (anonymous path): in onLinkAccount, explicitly call internalAdapter.deleteSessions(anonymousUser.user.id) before allowing the new session to be issued.

Credit

Reported by @iruizsalinas.

Resources

Impact

  • Stale session validity: a deleted user's existing session cookie continues to authenticate against getSessionFromCtx until the session TTL elapses (default 7 days). Within that window, the deleted user retains their pre-existing read and write surface.
  • SCIM-driven deprovisioning gap: organizations using SCIM to revoke offboarded employees' access do not, in fact, revoke active sessions. The deleted account remains usable for up to 7 days after deprovisioning.

GHSA-2VG6-77G8-24MP has a CVSS score of 3.8 (Low). The vector is network-reachable, high privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.6.11); upgrading removes the vulnerable code path.

Affected versions

better-auth (>= 0.3.4, < 1.6.11) @better-auth/scim (>= 1.6.0, < 1.6.11)

Security releases

better-auth → 1.6.11 (npm) @better-auth/scim → 1.6.11 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Fixed in better-auth@<patched-version> and @better-auth/scim@<patched-version>. All four user-deletion call sites now invoke deleteSessions(userId) before deleteUser(userId) so sessions are evicted from secondary storage at the same time the user row is removed.

Frequently Asked Questions

  1. What is GHSA-2VG6-77G8-24MP? GHSA-2VG6-77G8-24MP is a low-severity security vulnerability in better-auth (npm), affecting versions >= 0.3.4, < 1.6.11. It is fixed in 1.6.11.
  2. How severe is GHSA-2VG6-77G8-24MP? GHSA-2VG6-77G8-24MP has a CVSS score of 3.8 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which packages are affected by GHSA-2VG6-77G8-24MP?
    • better-auth (npm) (versions >= 0.3.4, < 1.6.11)
    • @better-auth/scim (npm) (versions >= 1.6.0, < 1.6.11)
  4. Is there a fix for GHSA-2VG6-77G8-24MP? Yes. GHSA-2VG6-77G8-24MP is fixed in 1.6.11. Upgrade to this version or later.
  5. Is GHSA-2VG6-77G8-24MP exploitable, and should I be worried? Whether GHSA-2VG6-77G8-24MP is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether GHSA-2VG6-77G8-24MP is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix GHSA-2VG6-77G8-24MP?
    • Upgrade better-auth to 1.6.11 or later
    • Upgrade @better-auth/scim to 1.6.11 or later

Other vulnerabilities in better-auth

CVE-IDSeverityPackage summary
CVE-2026-53518High@better-auth/oauth-provider: @better-auth/oauth-provider's OAuth authorization-code grant allows concurrent redemption when two token requests race the find-then-delete…CVE-2026-53517High@better-auth/oauth-provider: Better Auth: OAuth refresh-token rotation forks the token family on concurrent redemptionGHSA-9H47-PQCX-HJR4Highbetter-auth: Better Auth has insecure cryptographic defaults in oidcProvider: alg=none advertised and plain PKCE accepted by defaultGHSA-86J7-9J95-VPQJHighbetter-auth: Better Auth has stored XSS in the auth-server origin via javascript: redirect_uri in oidc-provider and mcpCVE-2026-53516Highbetter-auth: Better Auth has an account takeover issue via OAuth auto-link to unverified pre-registered email

Stop the waste.
Protect your environment with Kodem.

Get a personalized demo
Get a personalized demo