9Router has an Authentication Bypass in Public LLM API via Spoofable X-9r-Real-Ip Header

Summary

9router determines whether an incoming request originates from localhost by trusting the X-9r-Real-Ip HTTP request header. This header is intended to be produced and sanitized exclusively by the bundled custom-server.js layer from the TCP socket address. In deployment modes where requests reach Next.js directly (the header is never stripped/regenerated), a remote, unauthenticated attacker can simply send X-9r-Real-Ip: 127.0.0.1 and be treated as a local client. This bypasses the API-key requirement on the public LLM API (/api/v1/*), granting unauthenticated access to the instance owner's configured provider resources.

Affected Component

• src/dashboardGuard.js
• isLocalRequest() — trusts the client-supplied X-9r-Real-Ip header to decide loopback origin
• canAccessPublicLlmApi() — grants access to /api/v1/* when isLocalRequest() returns true, skipping API-key validation
• Verified affected route: GET /api/v1/models
• Product version tested: 9router-app 0.5.4 (Next.js 16.2.9)

Root Cause

The authorization layer makes a security decision based on a client-controllable HTTP header. isLocalRequest() reads X-9r-Real-Ip and, if its value is a loopback address (127.0.0.1), classifies the request as local. The design assumes this header can only be set by the trusted custom-server.js wrapper (which derives it from the unspoofable socket address and strips any inbound copy). When the application is served without that wrapper, Next.js passes the attacker-supplied header through unchanged, so the trust assumption is violated:

Untrusted Client Input
        ↓
X-9r-Real-Ip: 127.0.0.1
        ↓
isLocalRequest()  → true
        ↓
canAccessPublicLlmApi()  → allowed (API key not required)
        ↓
200 OK

Attack Scenario

1. The instance is deployed in a mode that does not use custom-server.js, and the LLM API is reachable by the attacker (the default bind is 0.0.0.0).
2. The attacker sends a normal request to /api/v1/models and receives 401 Unauthorized (API key required for remote access).
3. The attacker re-sends the identical request with the single added header X-9r-Real-Ip: 127.0.0.1.
4. The request is classified as local, the API-key check is skipped, and the attacker receives 200 OK with the owner's model catalog and ongoing access to the LLM API.

Proof of Concept

Baseline Request

<img width="1211" height="402" alt="Screenshot 2026-06-19 174727" src="https://github.com/user-attachments/assets/170b635f-1bd6-4dfd-ad85-30a03a9f6f72" />

Exploit Request

<img width="1207" height="816" alt="Screenshot 2026-06-19 174844" src="https://github.com/user-attachments/assets/b7b4efde-c071-4aa2-ab13-9bde7c88a7b8" />

The only difference between the two requests is the addition of X-9r-Real-Ip: 127.0.0.1.

Impact

An unauthenticated remote attacker who can reach the service can bypass API-key enforcement on the public LLM API and act as a trusted local client. Consequences include:

• Unauthorized use of the owner's configured LLM provider connections
• Consumption of paid API credits / financial loss to the instance owner
• Abuse of upstream provider accounts via the proxy
• Enumeration of configured providers and available models

Remediation

• Do not trust X-9r-Real-Ip (or any X-9r-* header) when received directly from clients.
• Derive the client address for authorization from a trusted transport-level source, e.g. req.socket.remoteAddress, rather than a request header.
• If custom-server.js is required for the security model, fail closed when its trusted marker is absent, and explicitly strip/reject any inbound client-supplied X-9r-* headers at the edge.
• Document supported, secure startup modes so the application is not run in a configuration where the header is attacker-controllable.