Obot SSRF Vulnerability Exposes Cloud Metadata and Internal Services

Executive summary

Obot ≤ v0.22.1 accepts a remote MCP server URL supplied by users with Power User, Power User Plus, or Admin roles. The URL is fetched server‑side without any destination validation, enabling a non‑blind SSRF that can contact internal networks, link‑local addresses, and the cloud metadata service (169.254.169.254). Successful exploitation can disclose IAM credentials and other sensitive data. The issue scores 7.6 / 10 (High) on CVSS v3.1.

What is affected

• Obot platform versions ≤ 0.22.1
• Deployments where authentication is enabled and privileged users can register remote MCP servers
• The vulnerability is triggered automatically during the metadata‑sync reconciliation step; no additional user interaction is required after registration.

Severity and evidence

• CVSS v3.1: 7.6 (High) – AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N
• The advisory confirms that the remote URL is only checked for parseability and scheme (http/https). No IP range or hostname restrictions are applied.
• The response body is reflected in Obot error messages, proving the SSRF is non‑blind.

Business or operational impact

• An attacker who gains Power User‑level access can enumerate internal APIs, services, or databases that are otherwise unreachable from the internet.
• Access to the cloud metadata endpoint can leak temporary IAM credentials, enabling lateral movement into the cloud account and potential data exfiltration or resource abuse.
• Because the fetch occurs during routine reconciliation, the attack can be performed silently and repeatedly, increasing the window for data exposure.

Detection considerations

• Look for outbound HTTP(S) requests from Obot instances to private IP ranges (127.0.0.0/8, 169.254.0.0/16, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or IPv6 ULA addresses.
• Monitor Obot logs for error messages that include remote response bodies – these may contain data returned from internal services.
• Correlate authentication logs to identify privileged users who have registered remote MCP URLs.

Recommended defensive actions

1. Upgrade Obot to v0.23.0 or later. The release adds a unified egress choke point that rejects loopback, link‑local, RFC1918, and IPv6 ULA destinations at dial time.
2. If an immediate upgrade is not possible, enable the DisallowLocalhostMCP flag and extend its scope to cover the metadata‑fetch path.
3. Restrict the ability to register remote MCP servers to trusted administrators only.
4. Deploy network egress filtering (firewall or service mesh) that blocks outbound traffic to private address spaces from Obot pods/containers.
5. Rotate any IAM credentials that may have been exposed as a precaution.

Workarounds or mitigations, if supported

• Enabling DisallowLocalhostMCP mitigates loopback requests but does not block RFC1918 or metadata‑service addresses. Combine it with external network policies to cover those ranges.
• Use a reverse‑proxy that validates outbound URLs before allowing Obot to fetch them.

Patch or remediation status

• Patched in Obot v0.23.0 (released after the advisory). The patch is publicly available on the official repository.
• No official back‑port has been announced for earlier versions; organizations should plan an upgrade.

References

• Advisory: https://github.com/advisories/GHSA-jgh3-fggc-mcpm
• Obot release notes for v0.23.0
• CVSS calculator reference for vector AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N

Publication date and last checked date

• Publication date: 2026-09-18
• Last checked: 2026-09-19