GHSA-7w99-5wm4-3g79 @better-auth/oauth-provider's OAuth authorization-code grant allows concurrent redemption when two token requests race the find-then-delete primitive

• npm @better-auth/oauth-provider: >= 1.6.0, < 1.6.11 → fixed in 1.6.11 • npm better-auth: < 1.6.11 → fixed in 1.6.11

Am I affected? Users are affected if all of the following are true: • Their project depends on `@better-auth/oauth-provider` at a version `>= 1.6.0, = 1.4.8-beta.7, `, 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. Patches 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. Workarounds None of these close the bug fully without a code patch. Upgrading is the only good path. • Network-layer: deploy an authorization-server-aware reverse proxy (Envoy, NGINX with Lua, custom Cloudflare Worker) that holds an in-flight registry keyed by the `code` parameter and serializes concurrent requests for the same code. Fragile under multi-instance deployments unless the registry is shared (Redis-backed). • Database-layer: add a SQL or Mongo uniqueness constraint that prevents two `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. • Application-layer: wrap `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. Impact • Multiple independent token sets from a single authorization: forked access tokens, refresh tokens, and id tokens issued from the same code, all valid for the original user's authorization scope. • Detection bypass: standard OAuth single-use enforcement does not fire for the second redemption when both requests interleave through the read step. • Legacy-plugin reach: `oidc-provider` and `mcp` plugins share the primitive on the same surface, so deployments using them inherit the same impact. Credit Reported by @chdanielmueller. Resources • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition) • CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition • CWE-294: Authentication Bypass by Capture-replay • RFC 6749 §4.1.2: Authorization Response • OAuth 2.1 §4.1: Authorization Code Grant