Advisory · CVE-2026-101064
Obot MCP server registration let privileged users reach internal services
Obot before 0.23.0 did not validate destinations when privileged users registered remote MCP servers, enabling SSRF against internal services and cloud metadata endpoints.
- Vendor
- obot-platform
- Product
- Obot
- Identifier / CWE
- CVE-2026-101064
CWE-918 - Action timing
- Immediate
Explain it like I’m five
Obot let its trusted staff point the mail truck at any address, no questions asked, and the truck reported back what it found. A malicious staffer pointed it at the building's private vaults and had the contents read back to them in the delivery report.
- 01Privileged registration
Users with Power User or higher roles could register remote MCP servers in Obot before 0.23.0.
- 02No destination validation
The registration accepted arbitrary URLs without validating the destination.
- 03Coerced requests
An attacker with a privileged role coerced Obot into making requests to internal services and cloud metadata endpoints.
- 04Responses disclosed
The responses, potentially containing sensitive credentials, were disclosed back in error messages.
What happened
Obot before 0.23.0 contained a server-side request forgery vulnerability in remote MCP server registration. Privileged users could specify arbitrary URLs without destination validation, allowing attackers with Power User or higher roles to coerce Obot into making requests to internal services and cloud metadata endpoints, reading responses in error messages to disclose sensitive credentials.
The flaw is fixed in Obot 0.23.0, which validates registration destinations.
What to do
- Upgrade Obot to 0.23.0 or later.
- Review registered remote MCP server URLs for internal addresses, link-local endpoints, or unexpected hosts.
- Check logs for registration-time requests to cloud metadata endpoints or internal services.
- Rotate cloud credentials and service secrets reachable from the Obot deployment if such requests cannot be excluded.
Management note
SSRF from a privileged user is easy to dismiss as an insider problem, but stolen or phished privileged accounts are the common path. The destination allow-listing that the fix adds is the control that should have been there from the start for any feature that makes the server fetch a URL.