Obot CVE-2026-101064

Requires an authenticated account with the Power User, Power User Plus, or Admin role on an Obot instance <= v0.22.1 with authentication enabled and privileged users permitted to register remote MCP servers. The vulnerable path is RemoteRuntimeConfig.URL, which is validated only for parseability and http/https scheme; the metadata-sync fetch runs automatically during reconciliation, so no user interaction beyond registration is needed. Impact is maximized when Obot runs in a cloud environment with an instance-metadata credential endpoint (169.254.169.254) reachable. The one existing egress guard (DisallowLocalhostMCP) is disabled by default, only blocks loopback when enabled, and is absent entirely from the automatic metadata-fetch path - so default configurations offer no protection against internal, link-local, or RFC1918 destinations.

Signals are consistent and point to a real but role-gated issue. The CVSS 4.0 vector (AV:N/AC:L/PR:H/UI:N/VC:H/SC:H) and the vendor's CVSS 3.1 (7.6, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:L/A:N) both correctly encode network reachability, low attack complexity, high privilege requirement, no user interaction, and a scope change with high confidentiality impact - reflecting SSRF that reads cloud IAM credentials from 169.254.169.254. No EPSS score, no CISA KEV listing, and no public POC are provided, so this is 'no public exploit identified at time of analysis.' The dominant limiting factor is PR:H: exploitation requires an authenticated Power User, Power User Plus, or Admin account, which sharply narrows the attacker population to insiders or attackers who have already compromised a privileged account. There is no conflict among the signals; the main caveat is that impact hinges on deployment context (Obot running in a cloud environment with an attached instance-metadata credential). This is a genuine priority for cloud-hosted Obot instances that delegate MCP-server registration to non-admin privileged roles, but it is not mass-exploitable given the authentication barrier and low deployment footprint.

A user holding the Power User or higher role registers a remote MCP server whose URL points at http://169.254.169.254/latest/meta-data/iam/security-credentials/. Obot's controller automatically fetches OAuth discovery metadata from that URL during reconciliation with no destination validation, and because the response body is reflected in Obot's error messages, the attacker reads the host's cloud IAM credentials and pivots into the cloud account. No public POC is identified, but the non-blind, no-user-interaction fetch path makes reliable exploitation straightforward for a privileged user.