NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

Better Auth affected by external request basePath modification DoSGHSA-569q-mpph-wgww

Fix: ray-project/ray@70e7c72

GHSA-569q-mpph-wgww is a CWE-770 vulnerability in better-auth. A fix is available for better-auth — see the affected versions and patch details below.

Also known asCVE-2025-71401
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-569q-mpph-wgww.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs40th percentile — riskier than 40% of all scored CVEsHighest risk
0.00%0.32%0.64%0.95%0.3%0.5%0.5%0.5%Sep 26Nov 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

916other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
better-authnpm
18.7Mdownloads / week

Description

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.

<img width="838" height="414" alt="write" src="https://github.com/user-attachments/assets/a7b4dd17-75c3-49ef-9d08-6a2079d6a0ea" />

Here's the router receiving the poisoned basePath:

<img width="594" height="372" alt="router" src="https://github.com/user-attachments/assets/5fdf2862-9cd1-4b96-b146-18e67d904157" />

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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmbetter-authall versions1.4.2npm install better-auth@1.4.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for better-auth, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. 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.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

# 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-H
O3 Security · Impact-Aware SCA

Is GHSA-569q-mpph-wgww in your dependencies?

Find it across npm, including transitive dependencies.

Better Auth affected by external request basePath…