CVE-2026-56677: 
JavaScript vulnerability analysis and mitigation

CVE-2026-56677 is a Server-Side Request Forgery (SSRF) vulnerability combined with missing authentication in 9Router, an AI router and token saver application. The flaw exists in version 0.5.4 and earlier, specifically in the POST /api/auth/oidc/test endpoint, which accepts a user-controlled issuerUrl parameter and performs outbound HTTP requests without restricting private or loopback destinations. The vulnerability was first published to the GitHub Advisory Database on August 17, 2026, and carries a CVSS v3.1 base score of 8.6 (High) (GitHub Advisory, GitHub Security Advisory).

The root cause is twofold: CWE-918 (SSRF) and CWE-306 (Missing Authentication for Critical Function). The vulnerable code in src/app/api/auth/oidc/test/route.js passes the attacker-supplied issuerUrl directly to fetchOidcDiscovery() in src/lib/auth/oidc.js, which internally executes fetch(\${issuerUrl}/.well-known/openid-configuration`)without any host validation or IP blocklist enforcement. The endpoint requires no authentication, meaning any network-accessible attacker can trigger outbound connections from the server. The vulnerability exhibits two behaviors: blind/error-based SSRF (observable via JSON parse error messages when targeting non-OIDC services) and full data reflection SSRF (when a targeted internal service returns a valid OpenID configuration structure, the parsed fields includingtoken_endpointandjwks_uri` are reflected back to the attacker) (GitHub Advisory, GitHub Security Advisory).

An unauthenticated remote attacker can leverage this vulnerability to conduct internal network topology discovery and port scanning against the hosting infrastructure, targeting loopback (127.0.0.1) and private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). If an internal service returns a valid OIDC-structured JSON response, the attacker can manipulate the dashboard's OIDC configuration logic by injecting malicious endpoint values (e.g., a rogue token_endpoint), potentially enabling credential interception or further exploitation of downstream authentication flows. The confidentiality impact is rated Low (internal service enumeration), integrity impact is High (configuration manipulation), and availability impact is Low (GitHub Advisory).

A proof-of-concept is included in the official security advisory, demonstrating exploitation via a simple unauthenticated HTTP POST request using tools like Burp Suite. No evidence of in-the-wild exploitation has been reported, and the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.271% (19th percentile), indicating a relatively low near-term exploitation probability. The attack is fully automatable (no user interaction required, low complexity) against any internet-exposed 9Router dashboard instance running version 0.5.4 or earlier (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-facing 9Router dashboard instances (version ≤ 0.5.4) using tools like Shodan or Censys by searching for the application's default port (3000) or known HTTP response signatures.
2. Confirm unauthenticated access: Verify that the /api/auth/oidc/test endpoint is reachable without authentication by sending a test POST request with no session cookie or authorization header.
3. Port scanning / Blind SSRF: Send crafted POST requests with internal IP addresses and varying ports as the issuerUrl value to enumerate open ports. Observe response differences — a timeout or JSON parse error (e.g., {"error":"Unexpected token 'c', \"check vul\" is not valid JSON"}) confirms a successful TCP connection to the target port.

POST /api/auth/oidc/test HTTP/1.1
Host: <target>:3000
Content-Type: application/json

{"issuerUrl": "http://127.0.0.1:22", "clientId": "probe_only"}

4. Full data reflection SSRF: Set up a mock OIDC server on an attacker-controlled internal host (or via DNS rebinding) that returns a valid OpenID configuration JSON document with malicious endpoint values.
5. Inject malicious OIDC configuration: Point issuerUrl at the mock server. The 9Router backend fetches <issuerUrl>/.well-known/openid-configuration, parses the response, and reflects the attacker-controlled token_endpoint, jwks_uri, and other fields back in the HTTP 200 response — confirming full data feed manipulation.
6. Leverage reflected data: Use the reflected malicious OIDC endpoints to potentially redirect authentication token requests to an attacker-controlled server, enabling credential harvesting or further lateral movement within the internal network (GitHub Security Advisory, GitHub Advisory).

• Network: Outbound HTTP GET requests from the 9Router server process to internal RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or loopback (127.0.0.1) targeting /.well-known/openid-configuration paths; unusual outbound connections to non-standard internal ports (e.g., 22, 3306, 5432, 6379).
• Logs: Web server/application logs showing repeated unauthenticated POST requests to /api/auth/oidc/test with varying issuerUrl values pointing to internal IP ranges; JSON parse error responses such as {"error":"Unexpected token..."} in application logs indicating blind SSRF probing.
• Application Behavior: Successful HTTP 200 responses to /api/auth/oidc/test containing internal hostnames or IP addresses in authorizationEndpoint, tokenEndpoint, or jwksUri fields, indicating successful OIDC data reflection from internal services.

The vendor has released a patched version (5.6) of 9Router that addresses this vulnerability; users should upgrade from any version ≤ 0.5.4 immediately (GitHub Security Advisory). As interim workarounds, administrators should: (1) add authentication middleware to the /api/auth/oidc/test endpoint to require valid user sessions; (2) implement server-side IP resolution and blocklisting to reject requests targeting loopback (127.0.0.0/8, ::1), private (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and link-local addresses; (3) enforce https:// protocol scheme validation on the issuerUrl parameter; and (4) consider implementing an allowlist of permitted OIDC issuer domains and rate limiting on the endpoint.

The vulnerability was reported by security researcher HK4zCzi and published in the GitHub Advisory Database on August 17, 2026. Coverage appeared on The Hacker Wire, which published a dedicated article on the SSRF via the OIDC test endpoint (The Hacker Wire). No significant vendor statements beyond the official advisory or notable community debate have been identified at this time.