9router uses a hardcoded fallback JWT secret string "9router-default-secret-change-me" for signing dashboard session JWTs if the JWT_SECRET environment variable is not configured. This secret is publicly known and unchanged across all affected versions (>=0.2.21 <0.4.45). Attackers can forge valid JWT tokens signed with this secret to bypass authentication and gain full dashboard and API access. The vulnerable code was introduced in commit 23cfb19 and persists through an OIDC refactor that relocated but did not change the secret. The recommended fix is to require JWT_SECRET at startup and fail if unset, or generate and persist a unique secret on first boot, avoiding fallback to a public constant.

An attacker can bypass authentication entirely by forging JWT tokens signed with the known fallback secret. This grants full access to the 9router dashboard and API, allowing the attacker to read sensitive API keys and authentication tokens, change passwords, shut down the router, and modify all settings. The attacker can also pivot through other exposed interfaces such as the MCP stdio→SSE bridge. The impact is complete compromise of the affected 9router instance.

No official patch is currently documented. The recommended mitigation is to configure the JWT_SECRET environment variable with a strong, unique secret before starting 9router. The server should be modified to fail startup if JWT_SECRET is not set, preventing fallback to the insecure default. Alternatively, implement logic to generate and persist a random secret on first boot and never use the hardcoded fallback. Until this is done, any 9router instance without JWT_SECRET set remains vulnerable.