GHSA-569q-mpph-wgww
Better Auth affected by external request basePath modification DoS
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
better-authnpmDescription
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:
<img width="631" height="219" alt="headers" src="https://github.com/user-attachments/assets/b3fb0078-a62f-4058-9d0b-4afbd30c4953" />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
<img width="662" height="307" alt="attack" src="https://github.com/user-attachments/assets/5a9cfdb5-3db7-4504-9f0a-b3c32a6dc823" />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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | better-auth | all versions | 1.4.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for better-auth. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update better-auth to 1.4.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-569q-mpph-wgww is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-569q-mpph-wgww is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-569q-mpph-wgww. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-569q-mpph-wgww in your dependencies?
O3 detects GHSA-569q-mpph-wgww across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.