CVE-2026-49352: 9router hardcoded default fallback JWT secret allows authentication bypass

9router (npm package 9router, GitHub decolua/9router) is a Next.js 16 web application that serves an AI-router dashboard on port 20128. In versions

=0.2.21 and <=0.4.41, the JWT signing/verification secret is derived from process.env.JWT_SECRET || "9router-default-secret-change-me". When an operator runs the app without setting the JWT_SECRET environment variable (the default out-of-the-box configuration), the application falls back to a publicly known, hardcoded string. Any unauthenticated remote attacker who knows this string can forge a valid HS256 JWT, set it as the auth_token cookie, and bypass authentication entirely — accessing the dashboard and all protected API endpoints without credentials.

• Package/component affected: 9router-app (the Next.js dashboard application shipped by the 9router npm package / Docker image), specifically the JWT session module src/lib/auth/dashboardSession.js (v0.4.31–v0.4.41) and previously src/app/api/auth/login/route.js + src/middleware.js (v0.2.21–v0.4.30).
• Affected versions: >=0.2.21 and <=0.4.41 (verified against v0.4.41).
• Risk level: Critical. Complete authentication bypass. An unauthenticated remote attacker gains full access to the dashboard UI and every protected API endpoint (/api/keys, /api/settings/*, /api/providers/client, /api/cli-tools/*, /api/mcp/*, /api/shutdown, etc.), exposing API keys, provider credentials, settings, and allowing shutdown of the service.

Impact Parity

• Disclosed/claimed maximum impact: Authentication bypass — unauthenticated remote attacker forges auth_token cookie and gains full access to dashboard and API (authz_bypass, critical).
• Reproduced impact from this run: Full authentication bypass demonstrated against the real 9router Next.js server (v0.4.41) running without JWT_SECRET. A forged HS256 JWT signed with the known secret produced:
  • GET /dashboard → HTTP 200 (full 25 KB dashboard HTML served)
  • GET /api/keys → HTTP 200, body {"keys":[]} (protected API access)
  • No-cookie controls correctly returned 307 (redirect to /login) and 401.
• Parity: full — the claimed unauthenticated auth bypass was reproduced end-to-end on the production HTTP path, and the fixed version (v0.4.44) was shown to reject the identical forged token (negative control).
• Not demonstrated: Not applicable; the claim is auth bypass (not code execution), and auth bypass was fully demonstrated.

Root Cause

The JWT session module computes its HMAC secret at module-load time:

// src/lib/auth/dashboardSession.js (v0.4.41)
import { SignJWT, jwtVerify } from "jose";

const SECRET = new TextEncoder().encode(
  process.env.JWT_SECRET || "9router-default-secret-change-me"
);

The fallback literal "9router-default-secret-change-me" is a constant baked into the published source. The dashboard middleware (src/proxy.js → src/dashboardGuard.js) protects /dashboard/:path* and sensitive API paths by calling verifyDashboardAuthToken(token), which runs jwtVerify(token, SECRET) from the jose library. Because the fallback secret is identical on every installation that omits JWT_SECRET, an attacker can locally reproduce the exact SECRET bytes and sign an arbitrary JWT that the server will accept as genuine.

The login route (src/app/api/auth/login/route.js) issues tokens via createDashboardAuthToken, which signs { authenticated: true } with HS256 and a 24 h expiry. An attacker simply replicates this token offline — no password, no network interaction with the target is needed beyond submitting the cookie.

Fix commit: fe3ce25ae3cda48c0702c2d452e17f6ec214009d ("Update JWT_SECRET handling", released in v0.4.44/v0.4.45). The fix replaces the hardcoded fallback with loadJwtSecret(), which (1) uses JWT_SECRET if set, else (2) reads a persisted secret from <DATA_DIR>/jwt-secret, else (3) generates a random 32-byte hex secret via crypto.randomBytes(32) and writes it to disk (mode 0600). Each install therefore gets a unique, unguessable secret.

Reproduction Steps

1. Script: bundle/repro/reproduction_steps.sh (self-contained, portable, reuses the durable project cache at <project_cache_dir>/repo and <project_cache_dir>/repo-fixed).
2. What the script does:
   • Checks out / reuses the vulnerable 9router v0.4.41 and the fixed v0.4.44 from the cached git mirror, building each with npm run build (next build --webpack) if a build is not already present.
   • Starts the real 9router Next.js production server (next start -p 20128 -H 127.0.0.1) for the vulnerable version without JWT_SECRET set, waits for it to become healthy (/api/auth/status returns 200).
   • Forges an HS256 JWT (via bundle/repro/forge_jwt.py) with payload { "authenticated": true, "iat": <now>, "exp": <now+24h> } signed with the known secret 9router-default-secret-change-me, and sends it as the auth_token cookie to GET /dashboard and GET /api/keys.
   • Repeats the same forged-cookie requests against the fixed v0.4.44 server (also without JWT_SECRET) as a negative control.
   • Writes bundle/repro/runtime_manifest.json and exits 0 only when the vulnerable build accepts the forged token (200) and the fixed build rejects it (307 / 401).
3. Expected evidence of reproduction:
   • Vulnerable: GET /dashboard with forged cookie → HTTP 200 (dashboard HTML, 25 268 bytes); GET /api/keys with forged cookie → HTTP 200 {"keys":[]}; no-cookie → 307 / 401.
   • Fixed: GET /dashboard with forged cookie → HTTP 307 redirect to /login; GET /api/keys with forged cookie → HTTP 401 {"error":"Unauthorized"}.

Evidence

• Log files:
  • bundle/logs/reproduction_steps.log — full annotated run log.
  • bundle/logs/vuln_server.log — vulnerable server startup (Next.js 16.2.10, Ready, [DB] Driver: better-sqlite3).
  • bundle/logs/fixed_server.log — fixed server startup.
• HTTP artifacts:
  • bundle/artifacts/forged_jwt.txt — the forged token.
  • bundle/artifacts/http/vuln_forged_hdr.txt — HTTP/1.1 200 OK (dashboard served to forged cookie on vulnerable build).
  • bundle/artifacts/http/vuln_forged_resp.html — 25 268 bytes of dashboard HTML (<!DOCTYPE html>...).
  • bundle/artifacts/http/vuln_api_forged_resp.txt — {"keys":[]}.
  • bundle/artifacts/http/vuln_nocookie_hdr.txt — 307 redirect to /login.
  • bundle/artifacts/http/fixed_forged_hdr.txt — HTTP/1.1 307 Temporary Redirect, location: /login (forged token rejected by fixed build).
  • bundle/artifacts/http/fixed_api_forged_resp.txt — {"error":"Unauthorized"}.
• Key excerpt (vulnerable, forged cookie):

  VULN /dashboard (forged auth_token)-> 200   (expect 200 = BYPASS)
  VULN /api/keys (forged auth_token) -> 200   (expect 200 = API access)
  

• Key excerpt (fixed negative control):

  FIXED /dashboard (forged auth_token)-> 307 http://127.0.0.1:20128/login  (rejected)
  FIXED /api/keys (forged auth_token) -> 401   (rejected)
  

• Environment: Node v24.18.0, npm 11.16.0, Next.js 16.2.10, jose 6.x, Linux x86_64, server bound to 127.0.0.1:20128, DATA_DIR isolated per build, JWT_SECRET intentionally unset.

Recommendations / Next Steps

• Upgrade to 9router >=0.4.45 (contains the fix). The fix generates a random per-install secret when JWT_SECRET is unset.
• Set JWT_SECRET to a long, random value via environment variable in all deployments (Docker, systemd, npm global). Never rely on the fallback.
• Rotate any auth_token cookies / API keys issued by deployments that ran without JWT_SECRET, since they were effectively publicly forgeable.
• Restrict network exposure: bind the dashboard to localhost or place it behind authenticated reverse proxies; the app already has loopback/Origin gating for some spawn-capable routes, but the dashboard itself was reachable.
• Testing recommendation: add a regression test that asserts the app refuses to start (or refuses to verify tokens) when no JWT_SECRET and no persisted secret exist, and a test that a token signed with the old default literal is rejected after upgrade.

Additional Notes

• Idempotency: The script was run twice consecutively; both runs produced identical results (vulnerable 200/200, fixed 307/401) and exited 0. Builds are cached in the durable project cache and reused on subsequent runs.
• Negative control: The fixed v0.4.44 build (commit fe3ce25ae) was compiled and run under identical conditions (no JWT_SECRET, same forged token). Its middleware contains no occurrence of the hardcoded literal (verified via grep of .next/server/middleware.js), and it rejected the forged token, confirming the fix is effective and that the bypass is specific to the hardcoded-secret versions.
• Library-level cross-check: The forged token was independently verified with the real jose library (jwtVerify → OK with the known secret; → "signature verification failed" with a random secret) before the HTTP proof, matching the exact verification path used by verifyDashboardAuthToken.
• Scope note: next start prints a warning under output: standalone recommending node .next/standalone/server.js; this is cosmetic — next start correctly serves the built app and runs the proxy/middleware, as evidenced by the 200/307/401 responses.