9router: Reverse proxy locality collapse allows unauthenticated access to 9router /v1 APIs

CISA 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.

9Router is an AI router & token saver. Prior to 0.5.2, 9router treats loopback requests as trusted and allows /v1/* access without an API key, so a same-host reverse proxy that forwards public traffic to the backend through 127.0.0.1 causes src/dashboardGuard.js to misclassify external requests as local. A remote unauthenticated attacker can access /v1 APIs such as /v1/models and may abuse configured upstream provider credentials through /v1 proxy endpoints depending on enabled providers. This issue is fixed in version 0.5.2.

Source published

10 Jul 2026 15:39:23 UTC

Source modified

10 Jul 2026 16:55:03 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 · 8.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

9Router is an AI router & token saver. Prior to 0.5.2, 9router treats loopback requests as trusted and allows /v1/* access without an API key, so a same-host reverse proxy that forwards public traffic to the backend through 127.0.0.1 causes src/dashboardGuard.js to misclassify external requests as local. A remote unauthenticated attacker can access /v1 APIs such as /v1/models and may abuse configured upstream provider credentials through /v1 proxy endpoints depending on enabled providers. This issue is fixed in version 0.5.2.

Source published

Jul 10, 2026, 3:39:23 PM (timezone not stated)

Source modified

Jul 10, 2026, 4:55:03 PM (timezone not stated)

Observed here

7 Nov 2026 12:36:30 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 · 8.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

9Router is an AI router & token saver. Prior to 0.5.2, 9router treats loopback requests as trusted and allows /v1/* access without an API key, so a same-host reverse proxy that forwards public traffic to the backend through 127.0.0.1 causes src/dashboardGuard.js to misclassify external requests as local. A remote unauthenticated attacker can access /v1 APIs such as /v1/models and may abuse configured upstream provider credentials through /v1 proxy endpoints depending on enabled providers. This issue is fixed in version 0.5.2.

Source published

10 Jul 2026 17:17:01 UTC

Source modified

25 Oct 2026 15:10:00 UTC

Observed here

27 Oct 2026 15:15:18 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 · 8.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

## 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.

Source published

23 Sep 2026 18:12:26 UTC

Source modified

23 Sep 2026 18:27:57 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:C/C:L/I:L/A:L

Publisher rating · HIGH