CVE-2026-56681: Authentication Bypass via HTTP Header Spoofing in 9Router

The system architecture of 9Router employs a dual-layer setup consisting of a Next.js web application and a custom wrapper server defined in custom-server.js. This wrapper handles incoming client connections, resolves IP addresses from TCP sockets securely, sanitizes spoofable HTTP headers, and proxies requests to the Next.js backend.

Under normal execution, the system relies on this boundary to distinguish administrative loopback traffic from public clients. The core application exposes public LLM API routes under /api/v1/* which are intended to be guarded by robust API key validation mechanisms.

However, the application exposes a dangerous trust boundary by utilizing the custom header X-9r-Real-Ip to bypass security guards. If the Next.js server is directly exposed without the wrapper layer, this header falls entirely under client control, allowing unauthenticated remote access to internal API configurations.

The root cause is classified as CWE-807: Reliance on Untrusted Inputs in a Security Decision. The authentication logic inside the Next.js server utilizes a helper function named isLocalRequest() in src/dashboardGuard.js to authorize administrative operations.

This helper identifies loopback traffic by parsing the X-9r-Real-Ip header and matching it to local loopback addresses like 127.0.0.1 or ::1. It operates under the false assumption that only the trusted custom-server.js wrapper can write or forward this specific header.

If the application is deployed directly via standard platform mechanisms (such as next start on cloud providers or in bare Docker containers), the custom-server.js wrapper is completely bypassed. Consequently, an external attacker can append X-9r-Real-Ip: 127.0.0.1 to their HTTP requests. The backend evaluates this header, falsely asserts that the connection is local, and skips API key validation for all endpoints under /api/v1/*.

The vulnerability lies in how IP evaluation was handled prior to the patch. The custom-server.js file failed to properly validate if the physical socket connection originated from a loopback proxy before processing forwarding headers.

// Vulnerable logic flow in custom-server.js
const wrapped = (req, res) => {
  const ip = req.socket && req.socket.remoteAddress ? req.socket.remoteAddress : "";
  // Forwarding headers present = request arrived via a reverse proxy; loopback
  // socket is the proxy hop, not the end-user, so it must not be trusted as local.
  const viaProxy = !!(req.headers["x-forwarded-for"] || req.headers["x-real-ip"]);
  // Vulnerable trust of incoming headers occurs here

The patch introduced strict peer address verification and automated stripping of internal headers. The following diff outlines the secured logic in custom-server.js introduced in version 0.5.6:

@@ -10,10 +10,15 @@ http.createServer = (...args) => {
   const rest = args.filter((a) => typeof a !== "function");
   if (!handler) return origCreate(...args);
   const wrapped = (req, res) => {
-    const ip = req.socket && req.socket.remoteAddress ? req.socket.remoteAddress : "";
-    // Forwarding headers present = request arrived via a reverse proxy; loopback
-    // socket is the proxy hop, not the end-user, so it must not be trusted as local.
-    const viaProxy = !!(req.headers["x-forwarded-for"] || req.headers["x-real-ip"]);
+    const socketIp = req.socket && req.socket.remoteAddress ? req.socket.remoteAddress : "";
+    const xff = req.headers["x-forwarded-for"];
+    const xRealIp = req.headers["x-real-ip"];
+    const viaProxy = !!(xff || xRealIp);
+    const isLoopbackProxy = socketIp === "127.0.0.1" || socketIp === "::1" || socketIp === "::ffff:127.0.0.1";
+    // Trust forwarding headers only when the TCP peer is a local reverse proxy.
+    // Direct/public sockets remain keyed by the unspoofable peer address.
+    const proxyIp = xRealIp || (xff ? String(xff).split(",")[0].trim() : "");
+    const ip = isLoopbackProxy && proxyIp ? proxyIp : socketIp;
+    delete req.headers["x-9r-real-ip"];
+    delete req.headers["x-forwarded-for"];
+    delete req.headers["x-9r-via-proxy"];

The patched version validates whether socketIp is a true loopback address (127.0.0.1, ::1, or the IPv4-mapped IPv6 equivalent ::ffff:127.0.0.1). If the physical socket is not local, incoming forwarding headers are ignored and stripped, neutralizing spoofing attempts.

To exploit this vulnerability, an attacker must identify a target running 9Router where the Next.js application port (typically 3000) is exposed directly to the network. Alternatively, the target may be behind a reverse proxy that fails to strip custom HTTP headers from client requests.

An attacker craft an HTTP request to the /api/v1/models endpoint while injecting the X-9r-Real-Ip header. This allows the attacker to query the state of the router without providing any Authorization headers.

GET /api/v1/models HTTP/1.1
Host: target-9router-instance:3000
X-9r-Real-Ip: 127.0.0.1
User-Agent: Mozilla/5.0
Accept: application/json

Upon receiving this request, the backend's local request helper processes the injected header. It returns a 200 OK response containing the configured LLM providers and models, allowing the attacker to make unauthorized inferences using the host's paid API keys.

The impact of this vulnerability is significant for organizations relying on 9Router to manage LLM access. Exploitation allows unauthenticated remote actors to execute cost-incurring inference requests against configured models.

Furthermore, the bypass facilitates information disclosure of internal system configurations and API structures. Attackers can enumerate active service integrations, revealing third-party provider accounts associated with the host.

Because the vulnerability does not provide direct filesystem access or system command execution, the impact on confidentiality, integrity, and availability is rated as Low from a system standpoint, yielding a CVSS score of 7.3.

The fix introduced in version 0.5.6 successfully secures deployments that run through custom-server.js by dropping client-supplied headers. However, structural risks remain if system administrators execute the Next.js server directly via next start or similar commands.

Because the core security guard inside dashboardGuard.js was not modified to independently validate socket origins, deployments bypassing custom-server.js remain vulnerable even on version 0.5.6. The fix is only effective if the wrapper file remains the sole entry point for network traffic.

Additionally, if an upstream reverse proxy is configured to append client IPs rather than overwrite the X-Forwarded-For header, attackers might still manipulate the list parsing logic. Standard hardening must include dropping all X-9r-* headers at the network edge.