Intelligence
criticalVulnerabilityActive

9router Hardcoded JWT Secret Authentication Bypass – Defensive Analysis

9router uses a publicly committed hardcoded JWT secret as a fallback when JWT_SECRET environment variable is not configured, allowing unauthenticated attackers to forge valid session tokens and gain full dashboard/API access. This affects multiple public instances where operators failed to set the environment variable.

S
Sebastion

CVE References

Affected

9router >= 0.2.21<= 0.4.41

Vulnerability Description

This is a CWE-798 (Use of Hard-Coded Credentials) and CWE-347 (Improper Verification of Cryptographic Signature) vulnerability. The 9router authentication system relies on JWT tokens signed with a secret key. When the JWT_SECRET environment variable is not explicitly set by an operator, the application defaults to a hardcoded fallback string "9router-default-secret-change-me" that has been committed to the public GitHub repository and distributed in every release since v0.2.21. Since JWT signing depends entirely on secret entropy, knowledge of this string enables any unauthenticated attacker to cryptographically forge valid auth_token cookies that will be accepted by the middleware as legitimate dashboard and API authentication tokens.

PoC Significance

The proof-of-concept demonstrates that this vulnerability is trivially exploitable with no preconditions other than network access to a 9router instance. The attacker does not need valid credentials, does not need to discover the secret through side-channel attacks, and does not need special privileges—the secret is publicly available in the source repository. The reliability is 100% for any 9router deployment where an operator has not explicitly configured the JWT_SECRET environment variable. Given the widespread nature of infrastructure automation that uses default configurations, this vulnerability affects a material portion of public 9router instances. The attack is a complete authentication bypass with immediate impact to confidentiality, integrity, and availability of the dashboard and API surface.

Detection Guidance

Log Indicators: Monitor application logs for JWT validation events; look for successful authentications from unexpected source IPs or patterns that suggest token forgery (e.g., tokens created outside normal login flows). Configuration Audit: Scan deployment configurations (Docker Compose files, Kubernetes manifests, systemd units, environment files) for the presence or absence of JWT_SECRET environment variable definitions. Any 9router deployment without an explicitly set JWT_SECRET should be flagged. Network Detection: Monitor for POST requests to /api/auth/login or protected API endpoints from sources that have never performed legitimate interactive login; token reuse from multiple geographically dispersed or suspicious sources within short timeframes indicates token forgery. Runtime Inspection: Check the 9router process environment with ps aux or container inspection tools to verify JWT_SECRET is set to a non-default value. YARA Rule Concept: Hunt for the string "9router-default-secret-change-me" in source code repositories, configuration files, or process memory dumps within your environment.

Mitigation Steps

Immediate Actions: (1) Update all 9router instances to the latest patched version (v0.4.42 or later, if available, or await official patch). (2) For all deployments, mandatory environment variable enforcement: Set a strong, cryptographically random JWT_SECRET environment variable (minimum 32 bytes, base64-encoded) on every 9router instance before restart. Verify the setting persists across restarts. (3) Invalidate all existing JWT tokens by restarting the application after setting the new secret, or implement a token rotation mechanism. (4) Review access logs for the past 90 days for suspicious authentication patterns; flag any sessions that cannot be correlated with legitimate user login events. Long-term: Monitor the 9router project for an official security patch that removes the hardcoded fallback or enforces JWT_SECRET as a required configuration parameter (failing fast if not set). Implement configuration validation in your deployment pipeline to reject 9router containers/processes with JWT_SECRET unset.

Risk Assessment

Likelihood of Exploitation in the Wild: HIGH. This vulnerability requires only public knowledge (the secret is in the GitHub repo) and network access; no zero-day or sophisticated attack capability is needed. The barrier to exploitation is extremely low. Given that 9router is used for network routing/gateway functions, compromised instances could facilitate lateral movement, data exfiltration, or service disruption. Threat Actor Interest: HIGH. The advisory notes that "many public 9router servers" are already affected, suggesting that either active exploitation is occurring or misconfigurations are widespread. Opportunistic threat actors, botnet operators, and targeted attackers have all demonstrated interest in hardcoded credential vulnerabilities in infrastructure software. Exploitability: TRIVIAL. A Python or Node.js script using standard JWT libraries and the known secret can generate valid tokens in seconds. No special skills or tools required. Recommend: Treat all unpatched 9router instances with unserialized JWT_SECRET as compromised until proven otherwise. Conduct immediate incident response on affected deployments.