CVE-2026-56682

9Router is an AI router & token saver. Prior to 0.5.6, 9Router deployments that allow requests to reach Next.js without the sanitizing custom-server.js wrapper use the client-supplied X-9r-Real-Ip value as the bucket key in getClientIp, checkLock, and recordFail in src/lib/auth/loginLimiter.js for POST /api/auth/login. A remote unauthenticated attacker can rotate the header on every password guess so each request uses a new failed-attempt bucket and the five-attempt progressive lockout never returns HTTP 429. This permits unthrottled password guessing against the dashboard login and can lead to an administrative session if the password is recovered. This issue is fixed in version 0.5.6.

9Router is an AI router & token saver. Prior to 0.5.6, 9Router deployments that allow requests to reach Next.js without the sanitizing custom-server.js wrapper use the client-supplied X-9r-Real-Ip value as the bucket key in getClientIp, checkLock, and recordFail in src/lib/auth/loginLimiter.js for POST /api/auth/login. A remote unauthenticated attacker can rotate the header on every password guess so each request uses a new failed-attempt bucket and the five-attempt progressive lockout never returns HTTP 429. This permits unthrottled password guessing against the dashboard login and can lead to an administrative session if the password is recovered. This issue is fixed in version 0.5.6.

Summary

9router enforces a progressive login lockout (5 failed attempts → temporary 30s+ lock) keyed on the client IP. The client IP used for this limiter is taken from the X-9r-Real-Ip request header, which is intended to be set only by the bundled custom-server.js layer from the unspoofable TCP socket address. In deployment modes where requests reach Next.js directly, a remote attacker controls this header and can assign a unique value to every request. Because each distinct header value maps to a fresh limiter bucket, the lockout never triggers, enabling unlimited password guessing against the dashboard login endpoint. This was reproduced against a live instance: a fixed header value was locked out (429) after 5 attempts, while rotating the header produced unlimited 401 responses with no lockout.

Affected Component

• src/lib/auth/loginLimiter.js
  • getClientIp() — derives the rate-limit bucket key from the client-supplied X-9r-Real-Ip header
  • checkLock() / recordFail() — per-IP progressive lockout (MAX_FAILS_BEFORE_LOCK = 5)
• src/app/api/auth/login/route.js — login endpoint protected by the above limiter

Root Cause

The brute-force protection partitions failed-attempt counters by client IP, but obtains that IP from a client-controllable HTTP header rather than from the transport layer. getClientIp() returns the value of X-9r-Real-Ip directly. The design assumes this header is produced and sanitized only by the trusted custom-server.js wrapper. When the application is served without that wrapper, the header passes through unmodified, so the attacker chooses the bucket key. Since the lockout is per-bucket, assigning a new value per request keeps every counter below the threshold:

Untrusted Client Input
        ↓
X-9r-Real-Ip: <attacker-chosen, rotated each request>
        ↓
getClientIp()  → distinct bucket per request
        ↓
recordFail()/checkLock()  → threshold (5) never reached
        ↓
unlimited 401 attempts, no 429 lockout

Attack Scenario

1. The instance is deployed in a mode that does not use custom-server.js, and the login endpoint is reachable by the attacker (the default bind is 0.0.0.0).

2. The attacker submits password guesses to POST /api/auth/login, setting a different X-9r-Real-Ip value on each request (e.g., 10.0.0.1, 10.0.0.2, ...).

3. Each request is counted against a new bucket, so the limiter always reports remaining attempts and never returns 429.

4. The attacker continues guessing without throttling until the dashboard password is recovered, yielding an authenticated admin session.

Proof of Concept

Baseline — fixed header value (lockout enforced)

Repeated POST /api/auth/login with a constant X-9r-Real-Ip: 9.9.9.9 and body {"password":"wrong"}:

POST /api/auth/login HTTP/1.1
Host: victim.example.com:20127
X-9r-Real-Ip: 9.9.9.9
Content-Type: application/json
Content-Length: 20
Connection: close

{"password":"wrong"}

Observed responses (sequential):

#1 → 401  {"error":"Invalid password. 4 attempt(s) left before lockout.","remainingBeforeLock":4}

#2 → 401  {"error":"Invalid password. 3 attempt(s) left before lockout.","remainingBeforeLock":3}

#3 → 401  {"error":"Invalid password. 2 attempt(s) left before lockout.","remainingBeforeLock":2}

#4 → 401  {"error":"Invalid password. 1 attempt(s) left before lockout.","remainingBeforeLock":1}

#5 → 429  Retry-After: 30
          {"error":"Too many failed attempts. Try again in 30s. ...","retryAfter":30}

Exploit — rotated header value (lockout bypassed)

Same request and body, but a different X-9r-Real-Ip per request, sent while 9.9.9.9 was already locked:

POST /api/auth/login HTTP/1.1
Host: victim.example.com:20127
X-9r-Real-Ip: 10.0.0.1
Content-Type: application/json
Content-Length: 20
Connection: close

{"password":"wrong"}

Observed responses:

X-9r-Real-Ip: 10.0.0.1 → 401 …

9Router is an AI router & token saver. Prior to 0.5.6, 9Router deployments that allow requests to reach Next.js without the sanitizing custom-server.js wrapper use the client-supplied X-9r-Real-Ip value as the bucket key in getClientIp, checkLock, and recordFail in src/lib/auth/loginLimiter.js for POST /api/auth/login. A remote unauthenticated attacker can rotate the header on every password guess so each request uses a new failed-attempt bucket and the five-attempt progressive lockout never returns HTTP 429. This permits unthrottled password guessing against the dashboard login and can lead to an administrative session if the password is recovered. This issue is fixed in version 0.5.6.

9Router is an AI router & token saver. Prior to 0.5.6, 9Router deployments that allow requests to reach Next.js without the sanitizing custom-server.js wrapper use the client-supplied X-9r-Real-Ip value as the bucket key in getClientIp, checkLock, and recordFail in src/lib/auth/loginLimiter.js for POST /api/auth/login. A remote unauthenticated attacker can rotate the header on every password guess so each request uses a new failed-attempt bucket and the five-attempt progressive lockout never returns HTTP 429. This permits unthrottled password guessing against the dashboard login and can lead to an administrative session if the password is recovered. This issue is fixed in version 0.5.6.

Summary

9router enforces a progressive login lockout (5 failed attempts → temporary 30s+ lock) keyed on the client IP. The client IP used for this limiter is taken from the X-9r-Real-Ip request header, which is intended to be set only by the bundled custom-server.js layer from the unspoofable TCP socket address. In deployment modes where requests reach Next.js directly, a remote attacker controls this header and can assign a unique value to every request. Because each distinct header value maps to a fresh limiter bucket, the lockout never triggers, enabling unlimited password guessing against the dashboard login endpoint. This was reproduced against a live instance: a fixed header value was locked out (429) after 5 attempts, while rotating the header produced unlimited 401 responses with no lockout.

Affected Component

• src/lib/auth/loginLimiter.js
  • getClientIp() — derives the rate-limit bucket key from the client-supplied X-9r-Real-Ip header
  • checkLock() / recordFail() — per-IP progressive lockout (MAX_FAILS_BEFORE_LOCK = 5)
• src/app/api/auth/login/route.js — login endpoint protected by the above limiter

Root Cause

The brute-force protection partitions failed-attempt counters by client IP, but obtains that IP from a client-controllable HTTP header rather than from the transport layer. getClientIp() returns the value of X-9r-Real-Ip directly. The design assumes this header is produced and sanitized only by the trusted custom-server.js wrapper. When the application is served without that wrapper, the header passes through unmodified, so the attacker chooses the bucket key. Since the lockout is per-bucket, assigning a new value per request keeps every counter below the threshold:

Untrusted Client Input
        ↓
X-9r-Real-Ip: <attacker-chosen, rotated each request>
        ↓
getClientIp()  → distinct bucket per request
        ↓
recordFail()/checkLock()  → threshold (5) never reached
        ↓
unlimited 401 attempts, no 429 lockout

Attack Scenario

1. The instance is deployed in a mode that does not use custom-server.js, and the login endpoint is reachable by the attacker (the default bind is 0.0.0.0).

2. The attacker submits password guesses to POST /api/auth/login, setting a different X-9r-Real-Ip value on each request (e.g., 10.0.0.1, 10.0.0.2, ...).

3. Each request is counted against a new bucket, so the limiter always reports remaining attempts and never returns 429.

4. The attacker continues guessing without throttling until the dashboard password is recovered, yielding an authenticated admin session.

Proof of Concept

Baseline — fixed header value (lockout enforced)

Repeated POST /api/auth/login with a constant X-9r-Real-Ip: 9.9.9.9 and body {"password":"wrong"}:

POST /api/auth/login HTTP/1.1
Host: victim.example.com:20127
X-9r-Real-Ip: 9.9.9.9
Content-Type: application/json
Content-Length: 20
Connection: close

{"password":"wrong"}

Observed responses (sequential):

#1 → 401  {"error":"Invalid password. 4 attempt(s) left before lockout.","remainingBeforeLock":4}

#2 → 401  {"error":"Invalid password. 3 attempt(s) left before lockout.","remainingBeforeLock":3}

#3 → 401  {"error":"Invalid password. 2 attempt(s) left before lockout.","remainingBeforeLock":2}

#4 → 401  {"error":"Invalid password. 1 attempt(s) left before lockout.","remainingBeforeLock":1}

#5 → 429  Retry-After: 30
          {"error":"Too many failed attempts. Try again in 30s. ...","retryAfter":30}

Exploit — rotated header value (lockout bypassed)

Same request and body, but a different X-9r-Real-Ip per request, sent while 9.9.9.9 was already locked:

POST /api/auth/login HTTP/1.1
Host: victim.example.com:20127
X-9r-Real-Ip: 10.0.0.1
Content-Type: application/json
Content-Length: 20
Connection: close

{"password":"wrong"}

Observed responses:

X-9r-Real-Ip: 10.0.0.1 → 401 …