Am I affected?

You are affected if all of the following are true:

- You use better-auth at a version >= 1.6.0, < 1.6.11. - The deviceAuthorization plugin is enabled in your auth config (deviceAuthorization() in your plugins array). - A third party can observe a pending user code before the legitimate user completes verification.

The standard device-flow UX displays user codes to humans, so realistic exposure includes shoulder-surfing, screen-share, voice or video calls, support-chat transcripts, referrer headers, and shared logs.

If your application does not enable the deviceAuthorization plugin, you are not affected.

Fix:

1. Upgrade to better-auth@1.6.11 or later. 2. If you cannot upgrade, see workarounds below.

Summary

Better Auth's deviceAuthorization plugin treated any authenticated session as the owner of any pending device code. The ownership gate on POST /device/approve and POST /device/deny short-circuited whenever the row's userId was unset, and the GET /device verification handler did not claim the row. An authenticated attacker who learned a valid usercode before the legitimate user completed approval could bind the polling device to the attacker's account or deny the legitimate flow.

Details

The device authorization flow binds the polling device to the user who entered the user code on the verification page. In affected versions, the plugin only created that binding at approve or deny time, with no claim at the verification step. The ownership check at approve and deny short-circuited when the owner was missing, accepting any authenticated caller instead of rejecting the request.

The fix changes GET /device to claim the pending row for the calling session. The approve and deny gates now require strict equality between the row's owner and the calling session. RFC 8628 §5.5 covers this risk class as Session Spying: a malicious party can hijack a session by completing authorization before the legitimate initiating user does.

Patches

Fixed in better-auth@1.6.11. After the patch, GET /device claims the pending row for the calling session, and POST /device/approve and POST /device/deny reject calls whose session does not match the claimed owner. Custom verification pages must serve GET /device to an authenticated session for the flow to succeed.

Workarounds

If you cannot upgrade immediately:

- Disable the plugin if you do not use the device flow: remove deviceAuthorization() from your plugins array. - Add a before hook on POST /device/approve and POST /device/deny that tracks which session called GET /device for each user code, and rejects calls from a different session. - Shorten the pending lifetime of device codes via the expiresIn plugin option to reduce the exploitation window.

Impact

- Account takeover on the polling device: the attacker's session becomes the device's session, so the device operates as the attacker. - Denial of the legitimate sign-in: the attacker can mark the code as denied, blocking the victim's flow.

Credit

Reported by Quikturn Security Team.

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.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. - Their application exposes /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). - Their application has not implemented an external mitigation: a load-balancer-level idempotency cache keyed by 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:

1. Upgrade to @better-auth/oauth-provider@1.6.11 or later. If developers use the legacy plugin paths from better-auth/plugins, upgrade better-auth to 1.6.11 or later. 2. If developers cannot upgrade, see workarounds below.

Summary

The OAuth provider's POST /oauth2/token endpoint, on the authorizationcode 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.

Details

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.

Patches

Fixed in @better-auth/oauth-provider@1.6.11 and better-auth@1.6.11 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 invalidgrant.

Error-code consistency is also tightened on the @better-auth/oauth-provider token endpoint: the malformed-verification-value branches previously returned a project-specific invalidverification code, which is not part of RFC 6749 §5.2's response error set. Both branches now return invalidgrant 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 invalidgrant 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