The report
A separate Gemini CLI issue examines requests made while an AI tool client bootstraps MCP OAuth. The metadata and dynamic-registration calls may use a different HTTP dispatcher from normal tool operations. The reporter's concern is that a URL can pass an earlier hostname check while the later connection resolves or redirects differently. This is a reported SSRF possibility, not verified access to an internal production service. Review the issue.
The security boundary is crossed before any normal MCP tool call. OAuth discovery is typically treated as a preparatory operation, but it is still a network request made on behalf of potentially untrusted configuration or endpoints. If the final connected address is not constrained, code that carefully validates regular MCP traffic may leave an earlier discovery step uncovered. The Case dossier distinguishes this bootstrap path from the unrelated fork-workflow secret concern.
What validation has to cover
Testing should use harmless local endpoints to compare URL parsing, DNS changes, redirects and the connected destination across all OAuth discovery and registration requests. A blocked request at configuration time does not prove that the transport enforces the rule on the actual socket. Conversely, the presence of multiple HTTP clients does not alone prove a successful SSRF exploit.
The issue provides no demonstrated real victim, no confirmed data extraction and no supported conclusion about a released fix. The useful result is a reproducible boundary question: do all network-capable phases share the same independently enforced destination policy?