CVE-2026-53518High· 8.1▾ Twilight@better-auth/oauth-provider's OAuth authorization-code grant allows concurrent redemption when two token requests race the find-then-delete primitive
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 44.6 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 16.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.5%
Users are affected if all of the following are true:
@better-auth/oauth-provider at a version >= 1.6.0, < 1.6.11, or uses the embedded plugin in better-auth >= 1.4.8-beta.7, < 1.6.0, or enables the legacy oidc-provider or mcp plugins from better-auth/plugins./api/auth/oauth2/token (or the legacy plugins' /oauth2/token and /mcp/token) as a token endpoint to OAuth/OIDC clients, including internal MCP clients (Claude Desktop, custom MCP tool callers, AI agents).code, a database trigger that rejects duplicate token issuance for the same authorization code, or a custom adapter override that performs an atomic compare-and-delete.Fix:
@better-auth/[email protected] or later. If developers use the legacy plugin paths from better-auth/plugins, upgrade better-auth to 1.6.11 or later.The OAuth provider's POST /oauth2/token endpoint, on the authorization_code grant, redeems a single-use authorization code through a non-atomic find-then-delete sequence. Two concurrent requests with the same code value both pass the read step before either delete completes, then both proceed to PKCE verification and createUserTokens. Each surviving request mints a fresh access token, refresh token, and id token. RFC 6749 §4.1.2 requires authorization codes to be single-use; this primitive does not enforce that under concurrency.
The same architectural primitive (find a single-use verification row, then delete it, then trust the row to authorize) is used in 20 other call sites across the codebase. The deletion primitive returns Promise<void>, discarding the row count surfaced by adapter.deleteMany, so no call site can detect "another caller already claimed this row". The fix lands at the primitive layer rather than at any individual call site.
The fix introduces a claimVerificationByIdentifier primitive at the internal-adapter layer that performs an atomic claim-and-return, replaces the find-then-delete pair at this call site, and migrates the highest-impact variant sites in the same release.
Fixed in @better-auth/[email protected] and [email protected] for the legacy oidc-provider and mcp plugin paths. All three token-exchange call sites now consume the verification row through internalAdapter.consumeVerificationValue, an atomic claim primitive that deletes the row and returns its prior value in one operation. The first request to arrive takes the row and mints tokens; concurrent racers observe an empty result and return invalid_grant.
Error-code consistency is also tightened on the @better-auth/oauth-provider token endpoint: the malformed-verification-value branches previously returned a project-specific invalid_verification code, which is not part of RFC 6749 §5.2's response error set. Both branches now return invalid_grant so spec-compliant clients can branch on the standard code without a special case.
None of these close the bug fully without a code patch. Upgrading is the only good path.
code parameter and serializes concurrent requests for the same code. Fragile under multi-instance deployments unless the registry is shared (Redis-backed).oauthAccessToken rows from being created with the same upstream code reference. Adapter-specific and not always feasible since the schema does not currently store the source code.deleteVerificationByIdentifier with a custom hook that uses adapter.deleteMany and surfaces the count, then injects an invalid_grant rejection when the count is zero. Requires forking the internal adapter.oidc-provider and mcp plugins share the primitive on the same surface, so deployments using them inherit the same impact.Reported by @chdanielmueller.
@better-auth/oauth-provider >= 1.6.0, < 1.6.11better-auth < 1.6.11Upgrade to a patched release:
@better-auth/oauth-provider 1.6.11better-auth 1.6.11Connected by shared product, vendor, weakness, or advisory.
CVE-2026-53517High· 8.1Better Auth: OAuth refresh-token rotation forks the token family on concurrent redemption
CVE-2026-53515High· 7.1@better-auth/sso: SSO provider may allow registration for any org member without a checking their role
GHSA-p2fr-6hmx-4528Medium· 6.4@better-auth/oauth-provider may provide access tokens for unauthorized audiences via unbound resource indicators
CVE-2026-53514High· 7.7Better Auth vulnerable to unauthorized invitation acceptance via unverified email match in organization plugin
CVE-2026-53516High· 8.3Better Auth has an account takeover issue via OAuth auto-link to unverified pre-registered email
GHSA-9h47-pqcx-hjr4High· 8.7Better Auth has insecure cryptographic defaults in oidcProvider: alg=none advertised and plain PKCE accepted by default