9Router CVE-2026-56677

Exploitation requires that 9Router's dashboard login feature is explicitly disabled - this is the stated precondition and the basis for CWE-306 classification; when dashboard authentication is enabled, the endpoint is not accessible to unauthenticated callers. The attacker must also have network-level access to the 9Router service port. No additional configuration, special protocol, or software state is required beyond those two conditions. What limits exploitation: deployments with dashboard auth enabled are not exposed; the vulnerability produces information disclosure of internal service metadata rather than direct code execution or data exfiltration of application secrets; scope is unchanged (S:U), so compromise does not automatically pivot to other systems without additional steps.

The NVD-assigned CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L) yields a score of 8.6, but the I:H metric warrants scrutiny - the described behavior is SSRF with information reflection, not direct data modification. High integrity impact is not substantiated by the description alone and may overstate the base score; realistic impact is low-to-moderate confidentiality (internal service discovery) with minimal direct integrity consequence unless the fetched OIDC metadata is subsequently used to manipulate authentication trust. EPSS data is not available in the provided intelligence, and the CVE is not listed in CISA KEV, indicating no confirmed active exploitation at time of analysis. The critical enabling condition - dashboard login being disabled - limits exposure to deployments that have explicitly or inadvertently removed authentication from the dashboard. This is a meaningful constraint, though self-hosted AI-proxy deployments running in trusted internal environments may commonly operate without dashboard auth. No POC has been identified. Real-world priority is moderate: niche product, conditional prerequisite, but trivially exploitable network enumeration once conditions are met.

An attacker with network access to an unauthenticated 9Router instance sends a POST request to /api/auth/oidc/test with an issuerUrl set to an internal address such as http://192.168.1.10:8080. The server fetches http://192.168.1.10:8080/.well-known/openid-configuration and returns the response body, allowing the attacker to confirm whether the internal host is live and extract any OIDC metadata fields it exposes. By iterating over internal IP ranges and ports, the attacker maps the internal service landscape without requiring credentials. No public POC has been identified, but the attack requires only standard HTTP tooling given the low complexity.