CVE-2026-55641: 9Router Authentication Bypass and SSRF Vulnerability

Technical summary

The vulnerability exists in 9Router's request routing logic for /v1 LLM proxy endpoints. The application implements a localization check by reading the Host HTTP header to distinguish between local and remote clients, using this determination as part of its authentication enforcement. Because HTTP headers are client-controlled, a remote attacker can set Host: localhost in a request, fooling the application into treating the request as local and skipping API key validation. This design flaw is compounded by two dangerous default behaviors: (1) the proxy forwards requests to upstream LLM providers using pre-configured credentials stored in the router, and (2) the /v1/search endpoint with searxng provider support accepts a baseUrl parameter that is not properly validated, allowing attackers to redirect server-side requests (SSRF) to arbitrary hosts including internal IP ranges or cloud metadata services (e.g., 169.254.169.254). The CWE classifications (CWE-1327: trust in the Client-Supplied HTTP Header, CWE-290: Improper Authentication, CWE-348: Use of Less Trusted Sources, CWE-918: Server-Side Request Forgery) accurately capture these flaws.

Business impact

Organizations deploying 9Router in their infrastructure to manage or optimize LLM API costs face immediate financial and confidentiality risks. An unauthenticated attacker can bypass all authentication controls and use the router's stored provider credentials to issue unlimited requests to upstream LLM services—AWS Bedrock, OpenAI, Anthropic, Google Vertex AI, or others—resulting in unexpected charges and API quota exhaustion. The SSRF capability via the searxng provider enables attackers to probe and exfiltrate data from internal services (databases, admin panels, Kubernetes APIs) or cloud metadata endpoints, potentially leading to credential theft and further compromise of the hosting environment. If 9Router is used in a multi-tenant or shared environment, this vulnerability breaks tenant isolation. For organizations relying on 9Router to audit or control LLM usage, the bypass renders their observability and cost controls ineffective.

Affected systems

9Router versions prior to 0.5.2 are vulnerable. The default configuration of 9Router is affected; organizations may have reduced attack surface if they have manually disabled the /v1 proxy endpoint or the searxng provider, but such configurations are likely uncommon. Any deployment accessible from a network where an attacker can send HTTP requests—including cloud deployments, on-premises networks with poor segmentation, or internet-facing instances—is at risk. The vulnerability requires network access to the 9Router instance but does not require authentication, making it exploitable by any network-adjacent attacker.

Exploitability

This vulnerability is straightforward to exploit and requires minimal sophistication. An attacker needs only to craft an HTTP request to the 9Router /v1 endpoint with a spoofed Host: localhost header and no authentication credentials. Standard tools like curl, Python requests, or any HTTP client are sufficient. The CVSS score of 8.2 (High) reflects the ease of exploitation (network-accessible, no authentication or user interaction required) combined with the severity of impact (confidentiality breach via credential misuse and SSRF, with some integrity impact via unauthorized API calls). The vulnerability is not present in current threat intelligence feeds (KEV status: false), but given its simplicity and the sensitive nature of LLM proxies, weaponization is likely. Organizations should assume active exploitation is or will be occurring.

Remediation

Upgrade 9Router to version 0.5.2 or later immediately. Version 0.5.2 addresses the vulnerability by implementing proper request origin validation that does not rely solely on client-supplied headers. After upgrading, verify that authentication is enforced on all /v1 proxy endpoints and validate that the searxng provider (if used) restricts baseUrl to an allowlist of approved services. As an interim mitigation for organizations unable to patch immediately, implement network-level access controls: restrict access to 9Router instances to trusted clients only, use a reverse proxy to inject a trusted X-Forwarded-For or X-Real-IP header and validate it server-side, or disable the /v1 proxy and searxng provider if not actively used. However, these mitigations are not substitutes for patching.

Patch guidance

Apply version 0.5.2 or later to all 9Router instances. Verify the patch by confirming the version in the application's status endpoint or logs. Test that API key authentication is now enforced; requests with a spoofed Host header and no API key should be rejected. If 9Router is deployed in a Kubernetes environment, update the container image and restart pods. If deployed as a standalone service, stop the current version, update to 0.5.2, and restart. Monitor for any configuration drift that may have weakened security controls during or after the upgrade. Confirm that stored provider credentials remain encrypted and that no credentials were exposed during the vulnerability window.

Detection guidance

Monitor 9Router access logs for requests to /v1 endpoints with a Host header of localhost or 127.0.0.1 that originate from non-localhost IP addresses. Requests with missing or invalid API key headers combined with these spoofed Host headers are strong indicators of exploitation. Monitor for suspicious /v1/search requests with searxng provider and baseUrl parameters pointing to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata endpoints (169.254.169.254, etc.). Correlate authentication logs: successful /v1 requests with no authentication credentials should be treated as incidents. Set alerts for any upstream LLM provider API calls that cannot be attributed to legitimate users or jobs. If available, enable request logging at your reverse proxy or load balancer layer to capture Host headers before they reach 9Router, providing defense-in-depth visibility.

Why prioritize this

This vulnerability should be prioritized as Critical for any organization running vulnerable 9Router instances in production. The combination of unauthenticated remote access, no user interaction required, and immediate access to stored credentials and SSRF capabilities justifies the CVSS 8.2 High score and demands urgent remediation. Unlike vulnerabilities requiring user interaction or advanced attack chains, this flaw can be exploited in seconds by any network-adjacent attacker. The financial impact (unauthorized LLM API usage) and confidentiality risk (credential theft, internal service reconnaissance) make this a clear and present danger to operations and budget.

Risk score, explained

The CVSS 3.1 score of 8.2 reflects Attack Vector: Network (the service is remotely reachable), Attack Complexity: Low (no special conditions required), Privileges Required: None (no authentication), User Interaction: None (the attack is fully automated), with impacts to Confidentiality (High—credentials and internal data exposed), Integrity (Low—unauthorized API calls but not data manipulation), and Availability (None—the service itself is not disrupted, though API quotas may be exhausted). The High severity designation appropriately signals that this is a serious flaw requiring immediate attention but does not escalate to Critical because the vulnerability does not directly compromise the confidentiality of end-user data stored in 9Router itself (the primary impact is credential and infrastructure misuse).

Frequently asked questions