GHSA-jgh3-fggc-mcpm

## Summary In affected versions, the URL of a remote MCP server is attacker-controlled at registration and is fetched server-side with no validation of the destination. There is no guard against loopback, link-local, RFC1918 private ranges, or the cloud metadata endpoint (`169.254.169.254`), so a use with the Power User, Power User Plus, or Admin role can coerce Obot into making requests to internal services and to the cloud instance metadata service, and read the responses. ## Am I affected? You are affected if you run Obot `<= v0.22.1` with authentication enabled and allow privileged users (with the Power User or higher privileges) to register remote MCP servers . The metadata-sync code path that triggers the fetch runs automatically during reconciliation, so no user interaction beyond registration is required. ## Details A remote server's URL (`RemoteRuntimeConfig.URL`) is accepted at registration after only checking that it is parseable and uses an `http`/`https` scheme — the destination is never constrained. Obot then connects to that URL when the server is launched or its OAuth state is checked, and the controller automatically fetches OAuth discovery metadata from it during reconcile. The one egress guard that exists (`DisallowLocalhostMCP`) is disabled by default, only blocks loopback when enabled, and is absent from the automatic metadata-fetch path. Because the fetched response body is reflected back in Obot's error messages, this is a non-blind SSRF. ## Impact An attacker can reach internal-only services and the cloud metadata service if they have the Power User, Power User Plus, or Admin role. Against `169.254.169.254` this can disclose the host's cloud IAM credentials, enabling a pivot into the cloud account. ## Mitigation Upgrade to **v0.23.0** or later, which applies a single outbound egress chokepoint — rejecting loopback, link-local (including `169.254.169.254`), RFC1918, and IPv6 ULA on the resolved IP at dial time — uniformly across the r