CVE-2026-55638: 9Router Authentication Bypass Vulnerability (CVSS 8.6)

Technical summary

The vulnerability arises from incomplete route coverage in src/dashboardGuard.js, which protects /v1, /v1beta, /api/v1, and /api/v1beta endpoints but excludes /codex. The next.config.mjs file contains a rewrite rule that transforms /codex/* requests to /api/v1/responses. Because this rewrite occurs after authentication checks, an unauthenticated attacker can reach protected functionality by sending requests to the unprotected /codex path. Once rewritten, these requests execute with the operator's LLM provider credentials (stored server-side), enabling unauthorized API calls to external providers. The CWE classifications (CWE-862: Missing Authorization and CWE-863: Incorrect Authorization) reflect the authentication bypass and authorization logic gap.

Business impact

A successful exploit allows attackers to make unauthorized calls to upstream LLM providers on behalf of the operator, potentially incurring substantial costs through token consumption. Depending on the provider's billing model and the attacker's volume, this could result in unexpected charges or service exhaustion. Additionally, the operator's stored credentials may be further compromised or exposed through verbose error messages or logging. Organizations running 9Router as part of their LLM infrastructure face both financial and reputational risk if an attacker generates suspicious API activity in their provider account.

Affected systems

The vulnerability affects 9Router versions prior to 0.5.2. No specific vendor or product count was disclosed in the advisory. Any organization deploying 9Router as a middleware layer for LLM API traffic is potentially at risk if running an unpatched version. The vulnerability has no bearing on upstream LLM providers (OpenAI, Anthropic, etc.) themselves—it is specific to 9Router's authentication layer.

Exploitability

Exploitability is straightforward and requires no authentication, special privileges, or user interaction. An attacker only needs to craft HTTP requests to /codex/* endpoints and can immediately bypass the API-key requirement. The vulnerability is accessible over the network with minimal complexity; there are no additional client-side requirements or environmental conditions. This makes the attack surface broad for any publicly exposed 9Router instance.

Remediation

Upgrade 9Router to version 0.5.2 or later. The fix applies authentication and authorization checks to the /codex endpoint before any URL rewrites occur, ensuring that all protected routes are covered consistently. Operators should verify the upgrade has been applied and test that unauthenticated /codex requests are now rejected. As an interim measure on older versions, network-level access controls or WAF rules can restrict traffic to /codex paths, though this is not a substitute for the patch.

Patch guidance

Update 9Router to version 0.5.2 or newer as soon as possible. Consult the official 9Router repository or release notes to confirm availability and deployment instructions for your environment. If you are running 9Router in a containerized or cloud-deployed setup, ensure the image or service definition pulls the patched version. Test the update in a staging environment first to confirm no downstream integrations are affected, though the patch is expected to be backward-compatible.

Detection guidance

Monitor your 9Router instance logs for repeated or unusual requests to /codex/* endpoints, especially from external or unexpected IP addresses. Check for a pattern of successful responses (HTTP 200, 201) followed by downstream API calls to LLM providers that don't correlate with your normal usage. If you have LLM provider billing alerts enabled, look for sudden spikes in API usage or token consumption immediately after your 9Router instance was publicly exposed. Review stored credentials access logs if available. A security audit of your LLM provider account's recent API activity is recommended even after patching, to identify and reverse any unauthorized calls.

Why prioritize this

This vulnerability merits immediate attention due to its high CVSS score (8.6), zero authentication requirement, and direct financial and operational impact. The simplicity of exploitation combined with the ease of chaining it to unauthorized API calls on behalf of the operator creates a critical risk. Organizations should treat this as urgent priority given the potential for rapid, large-scale abuse if 9Router is network-accessible.

Risk score, explained

The CVSS 3.1 score of 8.6 (HIGH) reflects a network-accessible vulnerability with low attack complexity, no authentication required, and high availability impact (through token exhaustion or service disruption). The integrity and confidentiality impacts are lower but present, as the attacker can trigger unauthorized actions and potentially extract information through error responses or logs. The score appropriately captures the balance between ease of exploitation and severity of outcome in this context.

Frequently asked questions