Better Auth CVE-2025-71399

Exploitation requires two concurrent conditions: (1) the target runs Better Auth prior to v1.4.5, and (2) the deployment does NOT normalize incoming URLs at the proxy or platform layer before they reach the Better Auth handler - specifically, //path must arrive at Better Auth as //path rather than /path. The bypass is limited to security controls implemented via disabledPaths configuration or path-based rate limiting; other authentication or authorization mechanisms are unaffected. Deployments on Vercel with Next.js (default URL normalization) or Cloudflare with 'Normalize URLs to origin' enabled are not exploitable. No authentication, account, or special role is required by the attacker.

The CVSS 4.0 score of 8.8 with AV:N/AC:L/AT:N/PR:N/UI:N reflects the trivial exploitability: any unauthenticated remote attacker with HTTP access can trigger the bypass without special tools or prerequisites. The VA:H metric captures the most severe impact - bypassing rate limits enables unbounded request flooding against authentication endpoints, potentially causing service exhaustion. VC:L and VI:L reflect that access to disabledPaths may expose sensitive endpoints, but the actual data or integrity impact varies per deployment's specific configuration. No EPSS score was provided in the input data. There is no CISA KEV listing and no confirmed POC, meaning this is assessed as not yet exploited at scale. A critical mitigating factor, noted explicitly in the advisory, is that many common deployment platforms (Vercel with Next.js, Cloudflare with URL normalization enabled) automatically collapse multiple slashes before requests reach Better Auth, rendering those environments unexploitable. Risk should therefore be treated as conditional on proxy configuration, not universally high.

An attacker targeting a Better Auth deployment that has disabled the /sign-in/email endpoint via disabledPaths sends a POST request to //sign-in/email instead. Because the proxy does not normalize URLs, Better Auth receives the double-slash path, rou3 strips the empty segment for routing but the disabled-path check has already evaluated the raw path and found no match, so the request is routed to the handler normally. No special tools or credentials are needed - a plain HTTP client suffices.