better-auth CVE-2026-67335

Exploitation requires all four of the following conditions to be simultaneously true: (1) the application runs better-auth at a version below 1.6.2; (2) the application explicitly sets betterAuth({ account: { storeStateStrategy: 'cookie' } }) - the default value 'database' is confirmed NOT affected, as database-backed state lookup enforces equality by key; (3) at least one OAuth provider is wired through genericOAuth({ config }) with pkce: false, or a custom getToken or tokenUrl is configured that does not require the stored codeVerifier in the token exchange - stock social providers with PKCE enabled are NOT affected; (4) the victim's browser holds a live oauth_state cookie, meaning the victim has initiated an OAuth login flow and the cookie has not yet expired, AND the identity provider accepts and returns an arbitrary code value to the callback endpoint. Limiting factors beyond the non-default configuration: the attacker must separately obtain a valid authorization code from the target provider (requiring their own provider account), and the victim must be socially engineered or redirected to complete the crafted callback request, making this a user-interaction-dependent attack per the CVSS 4.0 UI:P metric.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:P/VI:H) and resulting score of 6.0 accurately reflect substantial real-world friction: high attack complexity, specific attack prerequisites (AT:P), and required user interaction all reduce practical exploitability. The critical limiting factor is that the vulnerability only manifests when the application explicitly sets storeStateStrategy: 'cookie' - a non-default value - AND disables PKCE on at least one OAuth provider. The default database-backed strategy is confirmed unaffected. No CISA KEV listing exists, and no public exploit code has been identified, suggesting exploitation has not been observed at scale. Despite this, organizations whose deployments do match the affected configuration face a high-integrity impact: a successful attack results in full OAuth session hijacking or persistent account linkage, both serious authentication compromises. The CVSS 4.0 score of 6.0 is reasonable and consistent with the constrained conditions; the EPSS score is not provided in the input data, so probability of near-term exploitation cannot be quantified. Priority action is a configuration audit: any deployment confirming both storeStateStrategy: 'cookie' and pkce: false on a generic OAuth provider should treat this as high urgency.

An attacker targets a victim actively using an application that runs better-auth with storeStateStrategy: 'cookie' and a genericOAuth provider configured with pkce: false. After obtaining an attacker-controlled authorization code by authenticating with the same provider under their own account, the attacker delivers a crafted OAuth callback URL - via a phishing link, open redirect, or injected resource - that carries a forged state parameter and the attacker's code to /api/auth/oauth2/callback/<providerId> while the victim's browser still holds a live oauth_state cookie from their own sign-in initiation. Because parseGenericState does not compare the incoming state to the cookie's stored nonce, the server accepts the callback and mints a session in the victim's browser bound to the attacker's external identity, or links the attacker's provider account permanently to the victim's application profile.