Description

9Router is an AI router & token saver. In 0.5.4 and earlier, the POST /api/auth/oidc/test endpoint in src/app/api/auth/oidc/test/route.js passes the user-controlled issuerUrl parameter to fetchOidcDiscovery() in src/lib/auth/oidc.js without restricting private or loopback destinations, allowing unauthenticated attackers when dashboard login is disabled to scan internal services and reflect OIDC discovery fields including token_endpoint and jwks_uri.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.6",
  "pubDate": "2026-08-17T22:17:14.970Z",
  "pubdate": "2026-08-17T22:17:14.970Z",
  "executiveSummary": "An unauthenticated Server-Side Request Forgery (SSRF) vulnerability exists in 9Router version 0.5.4 and earlier within the OpenID Connect (OIDC) testing functionality. The flaw originates from the POST /api/auth/oidc/test endpoint, which processes a user-supplied issuerUrl parameter via fetchOidcDiscovery() without implementing network boundary validation or restricting access to private and loopback IP addresses.\nWhen dashboard login is disabled, unauthenticated malicious actors can leverage this endpoint to interact with internal network infrastructure, probe closed services, and execute port scanning operations from the perspective of the hosting server.\nFurthermore, the vulnerability permits the reflection of sensitive OIDC discovery metadata, including internal token_endpoint and jwks_uri values, back to the caller. This information disclosure combined with internal network mapping poses significant risk implications, allowing external attackers to bypass perimeter network defenses and map internal service topologies through the vulnerable AI router application.",
  "technicalDetails": "The vulnerability is rooted in inadequate input validation and the absence of destination IP filtering within the application logic governing OIDC discovery operations. Specifically, the vulnerable component is located in src/app/api/auth/oidc/test/route.js, which receives the user-controlled issuerUrl parameter via an HTTP POST request.\nWithout validating or sanitizing the input to ensure it points to a legitimate external OIDC provider, the route handler passes the untrusted URL directly to the fetchOidcDiscovery() function located in src/lib/auth/oidc.js.\nThe fetchOidcDiscovery() function subsequently initiates an outbound HTTP request to the specified target URL. Because the underlying HTTP client does not enforce network restrictions against RFC 1918 address space, loopback interfaces (127.0.0.1, ::1), link-local addresses, or cloud metadata services (e.g., 169.254.169.254), the application functions as an HTTP proxy for the attacker.\nThe attack flow proceeds as follows: an unauthenticated attacker identifies that dashboard login is disabled, exposing administrative or testing routes. The attacker crafts a malicious HTTP POST request to POST /api/auth/oidc/test, supplying a targeted internal URL or local loopback address within the issuerUrl parameter.\nThe 9Router server issues a request to the internal destination. If the internal service responds with valid OIDC discovery JSON structures or HTTP response data, the application parses and reflects these fields—such as token_endpoint and jwks_uri—back to the client in the HTTP response.\nThis behavior allows attackers to determine the operational status of internal ports, fingerprint internal web applications, and extract configuration details. The affected versions comprise 9Router 0.5.4 and all prior releases."
}