better-auth CVE-2025-71404

Exploitation requires that the target application is running better-auth version 0.0.2 through 1.1.15 and that the /api/auth/error route is reachable by a potential victim - this route is part of better-auth's default configuration and is not optional. The attacker must also coerce the victim into visiting a specially crafted URL (UI:A in CVSS 4.0), typically via phishing, QR code, or a redirect chain. No authentication is required from the attacker side (PR:N). The critical limiting factor is the mandatory user-interaction step: automated exploitation without victim participation is not possible for this reflected XSS class. Exploitation is further bounded by the victim's session and browser context - it does not affect other users or the server itself. Attacks against applications that sit behind SSO or that do not expose the /api/auth/error route publicly face a reduced but non-zero attack surface via authenticated users being redirected.

The CVSS 4.0 score of 5.1 (Medium) accurately captures the real-world risk profile: the UI:A metric is the decisive limiting factor, as exploitation is gated entirely on a victim clicking or being redirected to an attacker-controlled URL. Impact metrics VC:L/VI:L reflect the bounded but real consequences - session cookie theft, credential harvesting via fake login forms, and UI redressing are all plausible within the victim's browser session. The vulnerability is not listed in CISA KEV and no public exploit code has been confirmed, making opportunistic mass exploitation unlikely at present. EPSS data was not provided in the source intelligence. The absence of attack requirements (AT:N, AC:L) means that once a victim visits the URL, exploitation is reliable with no race condition or complex setup. The primary risk vector is targeted phishing using a legitimate-looking better-auth-hosted URL, which lends the attack inherent credibility. Overall, this is a genuine medium-priority finding: low barrier for a motivated attacker but limited blast radius without chaining to a follow-on attack such as session hijacking.

An attacker crafts a URL such as https://target-app.com/api/auth/error?error=%3Cscript%3Ealert(document.cookie)%3C/script%3E and delivers it to a victim via phishing email or malicious link, exploiting the legitimacy of the target application's own domain to bypass suspicion. When the victim clicks the link, better-auth reflects the unsanitized payload into the HTML response and the victim's browser executes the injected JavaScript within the application's origin. No public proof-of-concept has been identified at time of analysis, but the vulnerability class is trivially reproducible given knowledge of the affected endpoint.