CVE-2026-55501 in 9router
Summary
by MITRE • 07/10/2026
9Router is an AI router & token saver. Prior to 0.4.80, the dashboard login rate limiter in src/lib/auth/loginLimiter.js derives the client identity from the attacker-controlled X-Forwarded-For HTTP header, and src/app/api/auth/login/route.js uses that spoofable value for checkLock and recordFail. A remote attacker can rotate the X-Forwarded-For value on each login attempt to receive a fresh rate-limit bucket, bypass the 5-attempt threshold and progressive lockout durations, and perform unlimited brute-force attempts against the dashboard password. This issue is fixed in version 0.4.80.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/10/2026
The vulnerability in 9Router affects versions prior to 0.4.80 and represents a critical authentication security flaw that undermines the system's rate limiting mechanisms. The core issue stems from improper client identity determination within the authentication flow, specifically in how the system processes the X-Forwarded-For HTTP header. This header is commonly used by reverse proxies and load balancers to identify the original client IP address when requests pass through multiple layers of networking infrastructure. However, the 9Router implementation treats this attacker-controlled header as a definitive source of client identity without proper validation or sanitization.
The technical flaw exists in two interconnected components of the authentication system. The loginLimiter.js file in src/lib/auth extracts what it believes to be the client's IP address from the X-Forwarded-For header, while the route.js file in src/app/api/auth/login processes this potentially spoofable value for both checkLock and recordFail operations. This design creates a fundamental security weakness where an attacker can manipulate the HTTP header to appear as different clients, thereby circumventing the intended rate limiting protections that are meant to prevent brute-force attacks.
The operational impact of this vulnerability is severe and directly enables unlimited brute-force attempts against the dashboard password. An attacker can rotate the X-Forwarded-For value on each login attempt, effectively resetting the rate-limiting counters and bypassing the configured 5-attempt threshold with progressive lockout durations. This means that an attacker can make as many login attempts as needed without encountering the typical security controls designed to prevent credential stuffing or dictionary attacks. The consequence is that the system becomes vulnerable to automated password guessing attacks, potentially leading to unauthorized access to the dashboard and all associated administrative functions.
This vulnerability aligns with CWE-305 authentication weaknesses and represents a classic example of insecure input handling where untrusted data from HTTP headers is used without proper validation. From an ATT&CK perspective, this issue maps to T1110.003 (Credential Stuffing) and T1110.001 (Brute Force) techniques, as it removes the barriers that would normally slow down or prevent automated credential testing. The fix implemented in version 0.4.80 likely involves either proper validation of the X-Forwarded-For header to ensure its authenticity, implementation of additional client identification mechanisms, or removal of reliance on potentially spoofable HTTP headers for security-critical operations. Organizations should immediately update to version 0.4.80 or implement equivalent mitigations to protect against this vulnerability that could otherwise enable complete unauthorized access to the administrative dashboard.
The broader implications of this flaw extend beyond simple credential guessing, as it demonstrates a fundamental misunderstanding of how reverse proxy headers should be handled in security-sensitive contexts. The vulnerability highlights the importance of proper input validation and the principle of least privilege when dealing with authentication mechanisms. Security practitioners should consider implementing additional monitoring for suspicious login patterns and ensure that any system relying on HTTP headers for security decisions implements robust validation techniques to prevent header manipulation attacks.