CVE-2026-55641 in 9router
Summary
by MITRE • 07/10/2026
9Router is an AI router & token saver. Prior to 0.5.2, 9router determines whether a /v1 LLM proxy request is local by reading the client-controlled Host header, allowing a remote unauthenticated attacker to send Host: localhost and bypass API-key authentication. In the default configuration, this exposes the /v1 proxy to upstream provider calls using stored provider credentials and allows /v1/search with the searxng provider_options.baseUrl parameter to drive server-side requests to internal or cloud-metadata hosts. This issue is fixed in version 0.5.2.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/10/2026
The vulnerability in 9Router represents a critical authentication bypass flaw that stems from improper handling of client-controlled input within the HTTP Host header during LLM proxy request processing. This weakness allows remote unauthenticated attackers to manipulate the routing logic by injecting Host: localhost into their requests, effectively circumventing the API-key authentication mechanism that should protect the /v1 proxy endpoints. The vulnerability manifests due to a lack of proper validation and sanitization of the Host header field, which is typically considered a client-controlled parameter that should be carefully evaluated before being used in access control decisions.
The technical implementation flaw occurs when 9Router evaluates whether an incoming request should be treated as local by examining the Host header value directly without proper verification of its legitimacy. This approach violates fundamental security principles and creates a path for attackers to exploit the system's trust model. The vulnerability is particularly dangerous because it leverages HTTP header manipulation, a common attack vector that requires minimal privileges to exploit. When an attacker sends a request with Host: localhost, the system incorrectly treats this as a local request and grants access to protected functionality that should require proper authentication.
The operational impact of this vulnerability extends beyond simple authentication bypass to potentially enable unauthorized access to upstream provider services and internal network resources. In the default configuration, authenticated API keys are stored within the 9Router system and used to make requests to external LLM providers. However, the vulnerability allows attackers to leverage these stored credentials for unauthorized calls to upstream services, effectively enabling them to consume API credits or perform actions on behalf of legitimate users. Additionally, the issue enables server-side request forgery through the searxng provider_options.baseUrl parameter in /v1/search functionality, which can be exploited to make requests to internal hosts or cloud metadata endpoints that should remain protected from external access.
This vulnerability aligns with CWE-285 (Improper Authorization) and CWE-444 (Inconsistent Interpretation of HTTP Requests) while also demonstrating characteristics of ATT&CK technique T1071.004 (Application Layer Protocol: DNS) and T1190 (Exploit Public-Facing Application). The attack surface is particularly concerning because it allows for both credential theft through unauthorized API usage and potential internal network reconnaissance via server-side requests to metadata services or internal hosts.
The fix implemented in version 0.5.2 addresses the core issue by introducing proper validation of the Host header field, ensuring that only legitimate local host values are accepted for local request routing decisions. This typically involves implementing strict validation logic that verifies the Host header against known valid values or employs more robust authentication mechanisms that do not rely on potentially manipulated HTTP headers for access control decisions. Organizations using 9Router should immediately upgrade to version 0.5.2 or later and review their configurations to ensure that no unauthorized API keys have been used, while also implementing monitoring for suspicious patterns in proxy request behavior that might indicate exploitation attempts.
The vulnerability demonstrates the importance of not trusting client-controlled input for security decisions and highlights the need for proper input validation and sanitization across all network services. It also underscores the risk associated with using HTTP headers as primary factors in access control logic, particularly when those headers can be easily manipulated by remote attackers. Security practitioners should implement comprehensive monitoring for Host header manipulation attempts and consider implementing additional layers of authentication or authorization checks that are not dependent on potentially compromised client-controlled fields.
Organizations should also evaluate their network segmentation and access controls to ensure that even if such vulnerabilities exist, the blast radius remains limited. The vulnerability's exploitation requires minimal technical skill and can be automated, making it particularly dangerous in environments where 9Router is deployed without proper network restrictions or monitoring in place. Regular security assessments of proxy services and API gateways should include thorough testing of header handling logic to prevent similar issues from occurring in other systems that may have similar architectural patterns.
The incident serves as a reminder of the critical importance of secure coding practices, particularly around input validation and access control decisions. Systems should never rely on client-controlled data for security-critical decisions without proper validation, and all authentication mechanisms should be designed with the principle of least privilege in mind. The vulnerability also emphasizes the need for regular security updates and patch management processes to ensure that known vulnerabilities are addressed promptly before they can be exploited in the wild.