CVE-2026-56682 in 9Router
Summary
by MITRE • 09/22/2026
9Router is an AI router & token saver. Prior to 0.5.6, 9Router deployments that allow requests to reach Next.js without the sanitizing custom-server.js wrapper use the client-supplied X-9r-Real-Ip value as the bucket key in getClientIp, checkLock, and recordFail in src/lib/auth/loginLimiter.js for POST /api/auth/login. A remote unauthenticated attacker can rotate the header on every password guess so each request uses a new failed-attempt bucket and the five-attempt progressive lockout never returns HTTP 429. This permits unthrottled password guessing against the dashboard login and can lead to an administrative session if the password is recovered. This issue is fixed in version 0.5.6.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in versions of 9Router prior to 0.5.6 represents a critical authentication bypass mechanism rooted in improper input validation and rate limiting logic within the Next.js application layer. The core technical flaw lies in how the application handles client-supplied IP addresses for security controls. Specifically, when requests reach the Next.js server without being processed by the sanitizing custom-server.js wrapper, the system relies on the X-9r-Real-Ip header to determine the source of a login attempt. This value is subsequently used as the unique bucket key in functions such as getClientIp, checkLock, and recordFail located within src/lib/auth/loginLimiter.js for POST requests directed at /api/auth/login. By design, these mechanisms are intended to enforce progressive lockouts after five failed attempts, returning an HTTP 429 Too Many Requests status code to prevent brute-force attacks. However, because the application trusts a client-controlled header without sufficient verification or server-side IP resolution fallbacks, it fails to correctly associate multiple login attempts with a single attacker identity.
This architectural weakness allows a remote unauthenticated attacker to circumvent rate limiting protections through simple request manipulation. By rotating the X-9r-Real-Ip header value on every individual password guess, an attacker ensures that each attempt is treated as originating from a distinct IP address. Consequently, the application creates new, empty failure buckets for each request rather than incrementing counters within existing ones. This effectively neutralizes the five-attempt progressive lockout mechanism, permitting unthrottled and unlimited password guessing against the dashboard login interface. The operational impact of this flaw is severe, as it enables efficient brute-force attacks that can eventually recover valid credentials due to the absence of throttling delays or account locks. Once an administrative session is established through recovered passwords, the attacker gains full control over the router configuration, potentially leading to network compromise, data exfiltration, and further lateral movement within the protected infrastructure.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to correctly verify the identity of users during login attempts by allowing evasion of account lockout policies. It also relates closely to CWE-307 Improper Restriction of Excessive Authentication Attempts, which describes flaws where an application does not limit or restrict the number of failed authentication attempts within a given time frame. In terms of offensive security tactics, this exploitation technique maps directly to MITRE ATT&CK T1110 Brute Force and specifically sub-technique T1110.003 Password Spraying if multiple accounts were targeted, though in this context it is primarily used for single-account brute forcing due to the lack of rate limiting. The vulnerability highlights a common pitfall in modern web frameworks where reliance on forwarded headers without proper validation can undermine security controls implemented at the application logic level.
To mitigate this risk, organizations running 9Router must immediately upgrade to version 0.5.6 or later, which addresses the underlying issue by ensuring that rate limiting is applied correctly regardless of header manipulation. For deployments that cannot yet be upgraded, it is imperative to ensure that all incoming requests are processed through the sanitizing custom-server.js wrapper before reaching the Next.js application logic. Additionally, security teams should configure reverse proxies such as Nginx or Apache to strip or validate the X-9r-Real-Ip header based on trusted proxy chains rather than trusting client-supplied values directly in application code. Implementing server-side IP resolution using remote_addr from the actual TCP connection provides a more robust defense against this type of evasion. Monitoring for unusual patterns of login attempts, even if they appear to come from different IPs, can also help detect ongoing brute-force campaigns exploiting this flaw until patches are fully deployed across all instances.