CVE-2026-56675: 9router 9router /v1 APIs Has Unauthenticated Vulnerability

HIGH
Advisory Identifier: GHSA-x5c9-v98j-722r
CVSS 8.3
CWE-441 CWE-287 CWE-306 CWE-290
Published
Advisory Summary

CVE-2026-56675 is a HIGH (CVSS 8.3) 9router /v1 apis has unauthenticated vulnerability (CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')) affecting 9router libraries in the npm ecosystem. The issue involves 9router /v1 apis has unauthenticated access via reverse proxy locality collapse. Remediation is available by upgrading affected packages to version 0.5.2.

CVE-2026-56675 at a Glance

CVE Identifier CVE-2026-56675
GHSA Identifier GHSA-x5c9-v98j-722r
Severity HIGH
CVSS v3.1 Base Score 8.3
CWE Classification CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')
Affected Product 9router
Package Ecosystem npm
Published Date
Last Updated

Security Impact

CVSS: 8.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:C/C:L/I:L/A:L).

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

How to Fix CVE-2026-56675

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.2
npm install 9router@0.5.2
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-56675, 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.2), 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-441: Unintended Proxy or Intermediary ('Confused Deputy'), where the product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. this causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. 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 treats local loopback requests as trusted and allows access to `/v1/*` without an API key. In a documented/common reverse-proxy deployment where nginx forwards public traffic to the backend via `127.0.0.1`, external non-`Origin` requests are misclassified as local. This allows unauthenticated access to `/v1` APIs such as `/v1/models`, and may allow abuse of configured upstream provider credentials depending on the enabled providers. ## Details - **Affected version / commit:** 9router `v0.4.80` @ `b282f05`. - **Deployment precondition:** a same-host reverse proxy (e.g. nginx) forwarding public traffic to the backend on `127.0.0.1` / `localhost`. This mirrors the documented cloud deployment (`proxy_pass http://localhost:20128` with `X-Real-IP` / `X-Forwarded-For`). - **Observed behaviour:** - The **direct backend** (`direct-backend`, port `18081`) returns `401` for `/v1/models` without an API key. - A **direct request that spoofs** `X-9r-Real-IP: 127.0.0.1` still returns `401`: the custom server deletes the client-supplied header and overwrites it with the real socket address, so naive header spoofing does not work against the direct backend. - The **proxied path** (`reverse-proxy`, port `18080`) returns `200` with the full model catalog for the same `/v1/models` request **without any API key**. - A **proxied request that carries an `Origin` header** returns `401`. The bypass therefore primarily affects curl / SDK / server-side / non-browser clients, which do not send `Origin`. - **Root cause:** the backend's local/remote decision relies on perceived socket/loopback locality after reverse proxying. Because nginx connects to the backend from `127.0.0.1`, the backend stamps a loopback client address for **every** internet client and treats the request as local, skipping the `/v1` API-key requirement. The forwarded `X-Real-IP` / `X-Forwarded-For` headers that carry the true client IP are ignored for this decision. - This is **not** a simple client header-spoofing issue (the direct-spoof control above proves header spoofing is rejected); it is a property of how loopback proxy traffic is trusted. ## Proof of Concept This repository is a self-contained Docker Compose reproduction. No real provider is called and no real API key is required. 1. Build and start the stack: ```bash docker compose up --build ``` 2. Direct baseline (no API key): ```bash curl -i http://127.0.0.1:18081/v1/models ``` 3. Direct spoof control: ```bash curl -i -H "X-9r-Real-IP: 127.0.0.1" http://127.0.0.1:18081/v1/models ``` 4. Reverse-proxy bypass (no API key): ```bash curl -i http://127.0.0.1:18080/v1/models ``` 5. Reverse-proxy `Origin` control: ```bash curl -i -H "Origin: http://evil.example" http://127.0.0.1:18080/v1/models ``` ### Expected evidence | Request | Result | |---------|--------| | Direct `18081`, no key | `401 Unauthorized` (`{"error":"API key required for remote API access"}`) | | Direct `18081`, `X-9r-Real-IP: 127.0.0.1` spoof | `401 Unauthorized` | | Proxied `18080`, no key | `200 OK` with the full model catalog | | Proxied `18080`, with `Origin` | `401 Unauthorized` | ## Impact - Unauthenticated access to the `/v1` API surface in the affected reverse-proxy deployment. - Model enumeration via `/v1/models`. - Possible abuse of the operator's configured upstream provider credentials through `/v1/chat/completions` and other `/v1` proxy endpoints (the attacker spends the operator's provider quota/keys without holding any key of their own). - Actual impact depends on which providers are configured and how the instance is exposed to the public internet. - The attacker requires **no API key**. ## Suggested Fix - Do not use client/proxy/socket IP locality as an authentication bypass. - Require an API key by default for `/v1/*` on public listeners. - If local trust is genuinely needed, bind it to an unguessable server-generated secret or to a Unix domain socket that is only accessible locally — not to "the connection looks like loopback". - When running behind reverse proxies, use an explicit trusted-proxy configuration and a real client-IP derivation (e.g. a vetted `X-Forwarded-For` chain), and never treat all loopback proxy traffic as end-user-local. - Document a secure reverse-proxy configuration for operators.

CVE-2026-56675 Affected 9router Versions

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

References

Frequently Asked Questions

What is CVE-2026-56675?
CVE-2026-56675 is a security vulnerability in 9router involving 9router /v1 APIs has unauthenticated access via reverse proxy locality collapse under CWE-441: Unintended Proxy or Intermediary ('Confused Deputy').
Which 9router versions are affected?
Affected versions include releases prior to 0.5.2 across affected packages: 9router.
What version fixes CVE-2026-56675?
Upgrading to 0.5.2 (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.2. Upgrade your dependency to 0.5.2 or later.
What is the CVSS score of CVE-2026-56675?
CVE-2026-56675 has a CVSS v3.1 base score of 8.3 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L.
What CWE is associated with CVE-2026-56675?
CVE-2026-56675 is classified under CWE-441: Unintended Proxy or Intermediary ('Confused Deputy') (The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.).
How can I check npm dependencies for CVE-2026-56675?
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-x5c9-v98j-722r",
  "modified" : "2026-09-23T18:12:26Z",
  "published" : "2026-09-23T18:12:26Z",
  "aliases" : [ "CVE-2026-56675" ],
  "summary" : "9router /v1 APIs has unauthenticated access via reverse proxy locality collapse",
  "details" : "## Summary\n\n9router treats local loopback requests as trusted and allows access to `/v1/*` without an\nAPI key. In a documented/common reverse-proxy deployment where nginx forwards public\ntraffic to the backend via `127.0.0.1`, external non-`Origin` requests are misclassified as\nlocal. This allows unauthenticated access to `/v1` APIs such as `/v1/models`, and may allow\nabuse of configured upstream provider credentials depending on the enabled providers.\n\n## Details\n\n- **Affected version / commit:** 9router `v0.4.80` @ `b282f05`.\n- **Deployment precondition:** a same-host reverse proxy (e.g. nginx) forwarding public\n  traffic to the backend on `127.0.0.1` / `localhost`. This mirrors the documented cloud\n  deployment (`proxy_pass http://localhost:20128` with `X-Real-IP` / `X-Forwarded-For`).\n- **Observed behaviour:**\n  - The **direct backend** (`direct-backend`, port `18081`) returns `401` for `/v1/models`\n    without an API key.\n  - A **direct request that spoofs** `X-9r-Real-IP: 127.0.0.1` still returns `401`: the\n    custom server deletes the client-supplied header and overwrites it with the real socket\n    address, so naive header spoofing does not work against the direct backend.\n  - The **proxied path** (`reverse-proxy`, port `18080`) returns `200` with the full model\n    catalog for the same `/v1/models` request **without any API key**.\n  - A **proxied request that carries an `Origin` header** returns `401`. The bypass\n    therefore primarily affects curl / SDK / server-side / non-browser clients, which do\n    not send `Origin`.\n- **Root cause:** the backend's local/remote decision relies on perceived socket/loopback\n  locality after reverse proxying. Because nginx connects to the backend from `127.0.0.1`,\n  the backend stamps a loopback client address for **every** internet client and treats the\n  request as local, skipping the `/v1` API-key requirement. The forwarded `X-Real-IP` /\n  `X-Forwarded-For` headers that carry the true client IP are ignored for this decision.\n- This is **not** a simple client header-spoofing issue (the direct-spoof control above\n  proves header spoofing is rejected); it is a property of how loopback proxy traffic is\n  trusted.\n\n## Proof of Concept\n\nThis repository is a self-contained Docker Compose reproduction. No real provider is called\nand no real API key is required.\n\n1. Build and start the stack:\n   ```bash\n   docker compose up --build\n   ```\n2. Direct baseline (no API key):\n   ```bash\n   curl -i http://127.0.0.1:18081/v1/models\n   ```\n3. Direct spoof control:\n   ```bash\n   curl -i -H \"X-9r-Real-IP: 127.0.0.1\" http://127.0.0.1:18081/v1/models\n   ```\n4. Reverse-proxy bypass (no API key):\n   ```bash\n   curl -i http://127.0.0.1:18080/v1/models\n   ```\n5. Reverse-proxy `Origin` control:\n   ```bash\n   curl -i -H \"Origin: http://evil.example\" http://127.0.0.1:18080/v1/models\n   ```\n\n### Expected evidence\n\n| Request | Result |\n|---------|--------|\n| Direct `18081`, no key | `401 Unauthorized` (`{\"error\":\"API key required for remote API access\"}`) |\n| Direct `18081`, `X-9r-Real-IP: 127.0.0.1` spoof | `401 Unauthorized` |\n| Proxied `18080`, no key | `200 OK` with the full model catalog |\n| Proxied `18080`, with `Origin` | `401 Unauthorized` |\n\n## Impact\n\n- Unauthenticated access to the `/v1` API surface in the affected reverse-proxy deployment.\n- Model enumeration via `/v1/models`.\n- Possible abuse of the operator's configured upstream provider credentials through\n  `/v1/chat/completions` and other `/v1` proxy endpoints (the attacker spends the operator's\n  provider quota/keys without holding any key of their own).\n- Actual impact depends on which providers are configured and how the instance is exposed\n  to the public internet.\n- The attacker requires **no API key**.\n\n## Suggested Fix\n\n- Do not use client/proxy/socket IP locality as an authentication bypass.\n- Require an API key by default for `/v1/*` on public listeners.\n- If local trust is genuinely needed, bind it to an unguessable server-generated secret or\n  to a Unix domain socket that is only accessible locally — not to \"the connection looks\n  like loopback\".\n- When running behind reverse proxies, use an explicit trusted-proxy configuration and a\n  real client-IP derivation (e.g. a vetted `X-Forwarded-For` chain), and never treat all\n  loopback proxy traffic as end-user-local.\n- Document a secure reverse-proxy configuration for operators.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "9router"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.5.2"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.4.80"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/decolua/9router/security/advisories/GHSA-x5c9-v98j-722r"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-56675"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/decolua/9router/commit/da667836cc7584bea0edd893de1d590c9ea279dc"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/decolua/9router"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/decolua/9router/releases/tag/v0.5.2"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-287", "CWE-290", "CWE-306", "CWE-441" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-23T18:12:26Z",
    "nvd_published_at" : "2026-07-10T17:17:01Z"
  }
}