Description

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 trust the client-supplied X-9r-Real-Ip header in src/dashboardGuard.js when isLocalRequest decides whether canAccessPublicLlmApi may skip API-key validation for /api/v1/* routes. A remote unauthenticated attacker can set X-9r-Real-Ip to 127.0.0.1 and be classified as a local client, including on the verified GET /api/v1/models route. This permits unauthorized use of the instance owner's configured LLM providers, consumption of paid credits, and enumeration of configured providers and models. This issue is fixed in version 0.5.6.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-09-22T16:17:48.350Z",
  "pubdate": "2026-09-22T16:17:48.350Z",
  "executiveSummary": "A critical authentication bypass vulnerability exists in 9Router versions prior to 0.5.6, stemming from insecure trust in client-supplied HTTP headers for IP address verification.\nThe vulnerability occurs within the src/dashboardGuard.js component, which is responsible for enforcing access control. By manipulating the X-9r-Real-Ip header, an unauthenticated remote attacker can spoof their origin IP address as 127.0.0.1.\nThis deception causes the application's internal security logic (isLocalRequest) to misidentify the attacker as a trusted local client. Consequently, the system erroneously bypasses API-key validation for /api/v1/* routes.\nSuccessful exploitation allows unauthorized access to private LLM provider integrations, potentially leading to significant financial loss through the consumption of the instance owner's paid credits.\nFurthermore, attackers can enumerate configured LLM models and provider details, facilitating reconnaissance for further exploitation.\nThe vulnerability is primarily relevant in deployments where requests reach the underlying Next.js server without the protection of the intended custom-server.js sanitization wrapper.\nImmediate remediation involves upgrading to version 0.5.6 or ensuring the application is deployed behind a secure, properly configured proxy that strips unauthorized client-supplied headers before they reach the backend.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper implementation of network origin validation within the src/dashboardGuard.js file. The application relies on the X-9r-Real-Ip HTTP header to determine the client's IP address, which is then passed to the isLocalRequest function to decide whether access to the /api/v1/* routes should bypass API-key authentication requirements.\nIn a secure deployment, the application is expected to utilize a custom-server.js wrapper designed to sanitize incoming requests. However, when this wrapper is bypassed or absent, the server trusts the X-9r-Real-Ip header provided by the client without secondary verification. An unauthenticated attacker can supply this header in a malicious HTTP request with the value '127.0.0.1'.\nUpon receiving the request, the application’s logic in src/dashboardGuard.js evaluates the header. Because the logic prioritizes the spoofed header over the actual connection source, the isLocalRequest function evaluates to 'true'. This state forces the canAccessPublicLlmApi logic to assume the request originates from the local infrastructure, thereby relaxing security constraints that normally mandate a valid API key.\nThe attack flow is as follows: 1) The attacker initiates a GET request to a restricted endpoint, such as /api/v1/models; 2) The attacker injects the 'X-9r-Real-Ip: 127.0.0.1' header into the HTTP request; 3) The server-side logic in src/dashboardGuard.js processes the request, accepts the spoofed header, and sets the request context as 'local'; 4) The authentication middleware detects the 'local' flag and suppresses the API key validation process; 5) The server provides the requested data or executes the LLM proxy request, effectively bypassing the security boundary.\nThis vulnerability is present in all versions prior to 0.5.6. It is particularly severe because it transforms authenticated endpoints into public-facing, unauthenticated routes. The impact includes the unauthorized leakage of sensitive internal configuration data regarding LLM providers and the high probability of financial abuse, as the instance owner is billed for unauthorized usage of third-party LLM services. No specific privilege level is required; the vulnerability is accessible to any remote user capable of crafting arbitrary HTTP requests."
}