Summary
Affected versions of Better Auth allow an external request to configure baseURL when it isn’t defined through any other means. This can be abused to poison the router’s base path, causing all routes to return 404 for all users.
This issue is only exploitable when baseURL is not explicitly configured (e.g., BETTER_AUTH_URL is missing) and the attacker is able to make the very first request to the server after startup. In properly configured environments or typical managed hosting platforms, this fallback behavior cannot be reached.
Details
A combination of X-Forwarded-Host and X-Forwarded-Proto is implicitly trusted. This allows the first request to configure baseURL whenever it is not explicitly configured.
Here's the code that reads the headers:

Here's the call to getBaseURL(), the result is assigned to ctx.baseURL.

Here's the router receiving the poisoned basePath:

X-Forwarded-Host and X-Forwarded-Proto can be used to modify the pathname of a parsed URL object which forms baseURL. basePath is then derived from the pathname of baseURL. Once the router basePath is poisoned it fails to match & route incoming requests.
Repro
Start a better-auth server with no baseURL configuration.
Send the following request as the first request to the server:
curl -i --location 'https://example.com/api/auth/ok' \
--header 'X-Forwarded-Proto: some:' \
--header 'X-Forwarded-Host: junk'
The better-auth API check endpoint returns 404.
Now send a regular request without the X-Forwarded-Proto and X-Forwarded-Host headers.
curl -i --location 'https://example.com/api/auth/ok'
The better-auth API check endpoint still returns 404.
Example result

We have modified the basePath for the router until the server is restarted. An attacker can repeatedly send these attack requests aiming to persistently exploit the vulnerability.
References
Summary
Affected versions of Better Auth allow an external request to configure
baseURLwhen it isn’t defined through any other means. This can be abused to poison the router’s base path, causing all routes to return 404 for all users.This issue is only exploitable when
baseURLis not explicitly configured (e.g.,BETTER_AUTH_URLis missing) and the attacker is able to make the very first request to the server after startup. In properly configured environments or typical managed hosting platforms, this fallback behavior cannot be reached.Details
A combination of
X-Forwarded-HostandX-Forwarded-Protois implicitly trusted. This allows the first request to configure baseURL whenever it is not explicitly configured.Here's the code that reads the headers:
Here's the call to
getBaseURL(), the result is assigned toctx.baseURL.Here's the router receiving the poisoned
basePath:X-Forwarded-HostandX-Forwarded-Protocan be used to modify the pathname of a parsed URL object which formsbaseURL.basePathis then derived from the pathname ofbaseURL. Once the routerbasePathis poisoned it fails to match & route incoming requests.Repro
Start a better-auth server with no
baseURLconfiguration.Send the following request as the first request to the server:
The better-auth API check endpoint returns 404.
Now send a regular request without the
X-Forwarded-ProtoandX-Forwarded-Hostheaders.The better-auth API check endpoint still returns 404.
Example result
We have modified the
basePathfor the router until the server is restarted. An attacker can repeatedly send these attack requests aiming to persistently exploit the vulnerability.References