Vulnerability-Lookup

GHSA-X5C9-V98J-722R

Vulnerability from github – Published: 2026-09-23 18:12 – Updated: 2026-09-23 18:12

Summary

9router /v1 APIs has unauthenticated access via reverse proxy locality collapse

Details

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.

Build and start the stack: bash docker compose up --build
Direct baseline (no API key): bash curl -i http://127.0.0.1:18081/v1/models
Direct spoof control: bash curl -i -H "X-9r-Real-IP: 127.0.0.1" http://127.0.0.1:18081/v1/models
Reverse-proxy bypass (no API key): bash curl -i http://127.0.0.1:18080/v1/models
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.

Severity

8.3 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.80"
      },
      "package": {
        "ecosystem": "npm",
        "name": "9router"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56675"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-290",
      "CWE-306",
      "CWE-441"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-23T18:12:26Z",
    "nvd_published_at": "2026-07-10T17:17:01Z",
    "severity": "HIGH"
  },
  "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\u0027s 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\u0027s configured upstream provider credentials through\n  `/v1/chat/completions` and other `/v1` proxy endpoints (the attacker spends the operator\u0027s\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 \u2014 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.",
  "id": "GHSA-x5c9-v98j-722r",
  "modified": "2026-09-23T18:12:26Z",
  "published": "2026-09-23T18:12:26Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "9router /v1 APIs has unauthenticated access via reverse proxy locality collapse"
}

CVE-2026-56675 (GCVE-0-2026-56675)

Vulnerability from cvelistv5 – Published: 2026-07-10 15:39 – Updated: 2026-07-10 16:55

Title

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

Summary

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.

Severity

8.3 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

SSVC

Exploitation: none Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-07-10 16:54 UTC

CWE

CWE-287 - Improper Authentication
CWE-290 - Authentication Bypass by Spoofing
CWE-306 - Missing Authentication for Critical Function
CWE-441 - Unintended Proxy or Intermediary ('Confused Deputy')

Assigner

GitHub_M mitre root Scorecard

References

3 references

URL	Tags
https://github.com/decolua/9router/security/advis…	x_refsource_CONFIRM
https://github.com/decolua/9router/commit/da66783…	x_refsource_MISC
https://github.com/decolua/9router/releases/tag/v0.5.2	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
decolua	9router	Affected: < 0.5.2

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-56675",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-07-10T16:54:55.352353Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-07-10T16:55:03.329Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "9router",
          "vendor": "decolua",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.5.2"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "9Router is an AI router \u0026 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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "LOW",
            "baseScore": 8.3,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-287",
              "description": "CWE-287: Improper Authentication",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-290",
              "description": "CWE-290: Authentication Bypass by Spoofing",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-306",
              "description": "CWE-306: Missing Authentication for Critical Function",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-441",
              "description": "CWE-441: Unintended Proxy or Intermediary (\u0027Confused Deputy\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-07-10T15:39:47.530Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/decolua/9router/security/advisories/GHSA-x5c9-v98j-722r",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/decolua/9router/security/advisories/GHSA-x5c9-v98j-722r"
        },
        {
          "name": "https://github.com/decolua/9router/commit/da667836cc7584bea0edd893de1d590c9ea279dc",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/decolua/9router/commit/da667836cc7584bea0edd893de1d590c9ea279dc"
        },
        {
          "name": "https://github.com/decolua/9router/releases/tag/v0.5.2",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/decolua/9router/releases/tag/v0.5.2"
        }
      ],
      "source": {
        "advisory": "GHSA-x5c9-v98j-722r",
        "discovery": "UNKNOWN"
      },
      "title": "9router: Reverse proxy locality collapse allows unauthenticated access to 9router /v1 APIs"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-56675",
    "datePublished": "2026-07-10T15:39:23.282Z",
    "dateReserved": "2026-06-22T16:39:01.044Z",
    "dateUpdated": "2026-07-10T16:55:03.329Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-X5C9-V98J-722R

Summary

Details

Proof of Concept

Expected evidence

Impact

Suggested Fix

CVE-2026-56675 (GCVE-0-2026-56675)

Tags

Sightings

Nomenclature

Related by attack behaviour