You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(mcp): add SSRF protection to OAuth metadata discovery
The OAuth discovery flow in oauth-utils.ts and oauth-provider.ts
fetches URLs received directly from external MCP server responses
without any SSRF validation, unlike web-fetch.ts which already
uses isLoopbackHost() and resolveAndValidateDns() from utils/fetch.ts.
A malicious MCP server can return private/internal IPs in:
- WWW-Authenticate: Bearer resource_metadata="http://169.254.169.254/..."
- /.well-known/oauth-protected-resource: {authorization_servers: ["http://169.254.169.254"]}
- /.well-known/oauth-authorization-server: {registration_endpoint: "http://10.x.x.x/admin"}
This causes gemini-cli to make GET and POST requests to cloud IMDS
endpoints (AWS 169.254.169.254, GCP metadata.google.internal, Azure
169.254.169.254) or internal services on the developer's network.
Fix: apply the same isLoopbackHost() + resolveAndValidateDns() guards
already used in web-fetch.ts to:
- OAuthUtils.fetchProtectedResourceMetadata()
- OAuthUtils.fetchAuthorizationServerMetadata()
- MCPOAuthProvider.registerClient()
0 commit comments