better-auth CVE-2026-67337

Exploitation requires three concrete conditions to be simultaneously true: (1) the target application must have better-auth's two-factor authentication plugin enabled; (2) the session.cookieCache option must be enabled in the better-auth configuration - this is a non-default feature that must be explicitly opted into; and (3) the attacker must possess valid primary credentials (username and password) for a target account subject to 2FA, placing this in the CVSS PR:L (low-privilege) category. What limits exploitation: applications using better-auth without session.cookieCache, or without 2FA, are not affected; this is not a default-configuration attack. The bypass is also limited to confidentiality (access to protected routes and data) - there is no integrity or availability impact described or implied by the CVSS vector.

The CVSS 4.0 base score of 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) reflects that exploitation requires valid primary credentials (PR:L) but is otherwise straightforward over the network with no user interaction. The confidentiality impact is high on the vulnerable system, since 2FA is typically deployed to protect high-value accounts and sensitive routes. Critically, exploitation is conditional: both two-factor authentication and session.cookieCache must be simultaneously enabled, which is a non-default combination. The CVSS 4.0 vector assigns AT:N (no attack requirements beyond the attacker's control), but this understates the deployment prerequisite - only applications with both features active are affected. No public exploit code and no KEV listing exist at time of analysis, reducing immediate mass-exploitation risk. However, because the bypass is conceptually trivial once prerequisites are met (no memory corruption, no timing race - just a cache lookup ordering flaw), the barrier to exploitation is effectively the availability of valid credentials, not technical sophistication.

An attacker who has obtained valid username and password credentials for a target account - through phishing, credential stuffing, or prior breach - initiates a sign-in request against an application using better-auth with both 2FA and session.cookieCache enabled. After primary authentication succeeds, the resulting session is written to the cookie cache as valid before the 2FA challenge is presented. The attacker then makes a subsequent authenticated request; the cache returns the pre-2FA session as fully authenticated, and the application grants access to protected routes without the attacker ever supplying or intercepting a one-time code. No public exploit code is known to exist at time of analysis.