This CVE exposes an SSRF vector in 9Router's OIDC discovery implementation. The vulnerable component is an unauthenticated endpoint—likely a test or debug surface—that accepts an issuer URL parameter and passes it directly to the OIDC discovery fetch without network boundary validation. When dashboard login is disabled, this endpoint becomes reachable in production, allowing attackers to supply arbitrary URLs and trigger server-side requests to internal services, cloud metadata endpoints, or internal network hosts.
The root cause is not merely a missing blocklist. The underlying OIDC discovery library (fetchOidcDiscovery or equivalent) was designed to accept arbitrary URLs as a core feature—fetching configuration from any issuer is the library's purpose. The architectural gap is that the library provides no security primitives for constraining this capability. Every consumer inherits the vulnerability unless they independently remember to add SSRF protection, which the 9Router developers did not do for this endpoint. This is the same failure pattern that has produced SSRF vulnerabilities across OIDC libraries in multiple languages over the past decade.
What makes this endpoint exploitable is that it was almost certainly written for internal debugging, evaluated during development, and then forgotten—shipping as production code while retaining its 'test' nature. The 'when dashboard login is disabled' condition strongly suggests this was a debug endpoint that should have been stripped or guarded but survived through organizational neglect rather than intent.
Immediate actions: First, verify whether this specific endpoint exists in your 9Router deployment and whether it responds when dashboard login is disabled—this is the exploit precondition. Second, audit the codebase for other endpoints or utilities that perform URL fetching from user-supplied input without SSRF controls; this vulnerability class has a strong recurrence pattern. Third, if the library exposes the discovery function, consider wrapping it with network boundary validation at the application layer—restricting to non-private IP ranges, blocking known internal ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and denylisting cloud metadata endpoints (169.254.169.254). The fix should be a blocklist or allowlist at the call site, but the long-term architectural question is whether the library should provide safe defaults that consumers inherit rather than require.
Watch for: any OIDC client code that accepts issuer URLs from untrusted input without boundary constraints. The pattern is well-documented, the mitigations are known, and this CVE confirms the same gap exists in this codebase.