An AI agent connecting to an MCP tool can fetch OAuth metadata before it ever invokes a protected tool. If only the metadata URL is validated and the actual request is sent through a different transport, a controlled hostname can change resolution or redirect toward internal network resources. The issue describes this potential origin-to-connection…
Inspect the ClaimsCase · DiggingBeagle record
Gemini CLI MCP OAuth metadata requests may bypass safe network dispatch
An issue reports that OAuth metadata and registration fetches use a network path outside Gemini CLI MCP safe dispatch, leaving a DNS rebinding concern.
Localhost is not a trust boundary for agentsEndpoint identity binding in AI-assisted trust decisions
Scope
The public issue describes a potential SSRF condition without verified victim access or a merged correction.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- not established
- Evidence
- Grade D
- AI role
- AGAINST AI
Basis and provenance
The pinned Claim and its primary disclosure support the described controlled result, but do not establish a population-wide rate or calibrated impact. The only available supporting evidence is the reporter's or advisory author's own account; independent reproduction has not been shown. Impact remains unbanded because no calibrated impact rubric for this particular evidence is established.
Assessed Nov 2, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-NOV02-GEMINI-CLI-MCP-OAUTH-SSRF-A · Gemini CLI issue 30073: OAuth metadata fetches bypass safe dispatcher
At a glance
Network boundaries must be enforced on the actual connected destination for every pre-tool bootstrap request.
Read the implicationsThe public issue describes a potential SSRF condition without verified victim access or a merged correction. No completed private-network request, leaked token or released remediation is established in the issue thread.
Limits and uncertaintyFull account
An AI agent connecting to an MCP tool can fetch OAuth metadata before it ever invokes a protected tool. If only the metadata URL is validated and the actual request is sent through a different transport, a controlled hostname can change resolution or redirect toward internal network resources. The issue describes this potential origin-to-connection mismatch, not a confirmed successful attack against a private host or a public exploit campaign.
An OAuth URL can pass a one-time public-address check and still connect to a different IP when DNS is resolved for the actual HTTP request. The issue traces this discrepancy specifically to protected-resource discovery, authorization-server metadata and client registration, which use a different dispatcher from the hardened web-fetch path. The author explicitly labels the report a hardening concern, not a live DNS-rebinding demonstration or a token-leak incident. Private or loopback hosts deliberately enabled by an operator need a separate policy; a blanket block without considering that configuration would misstate the proposed fix.
Mechanism and trust boundary
- 01
MCP OAuth discovery begins
The client accepts a remote server address and examines its metadata URL.
Boundary: User-selected MCP server into OAuth bootstrap
- 02
Validation and connection differ
The metadata or registration request bypasses the validated safe dispatcher.
Boundary: URL policy decision into separate network connection
- 03
Network destination can change
DNS rebinding may redirect a later request to a private address if not rechecked.
Boundary: Hostname intent into connected IP authority
Claims & evidence
CLM-2026-NOV02-GEMINI-CLI-MCP-OAUTH-SSRF-AThe Gemini CLI issue identifies OAuth discovery and dynamic registration HTTP requests that do not use the same safe dispatcher as other MCP traffic, so a previously checked host may resolve differently at connection time.supported
Basis: reported finding
- supportsGemini CLI issue 30073: OAuth metadata fetches bypass safe dispatcherprimary disclosure
Issue 30073, metadata and registration request paths, DNS validation mismatch
Implications
Network boundaries must be enforced on the actual connected destination for every pre-tool bootstrap request.
Controls and mitigations
- Unify OAuth metadata and registration requests with the safe dispatcher; validate redirects, resolved IPs and connect-time destination.
- Bind DNS and connected-address validation to the actual OAuth metadata and registration sockets; reject a later private or loopback destination unless explicitly authorized.
Unknowns and contradictions
- The public issue describes a potential SSRF condition without verified victim access or a merged correction.
- No completed private-network request, leaked token or released remediation is established in the issue thread.
Sources and citation
Material revision history
- Nov 2, 2026 · Canonical change recorded · new in release · revision 214