Obot vulnerabilities

Obot before v0.23.0 contains a server-side request forgery vulnerability in remote MCP server registration that allows privileged users to specify arbitrary URLs without destination validation. Attackers with Power User or higher roles can coerce Obot to make requests to internal services and cloud metadata endpoints, reading responses in error messages to disclose sensitive credentials.

Obot versions before v0.23.0 fail to enforce authentication on MCP Registry endpoints under /v0.1/* when registry authentication is enabled. An unauthenticated attacker can read registry metadata including server names, descriptions, repository URLs, and connect URLs by sending GET requests to /v0.1/servers.

Obot before v0.23.0 (affected versions <= v0.22.1) with OBOT_SERVER_ENABLE_AUTHENTICATION=true exposes OAuth dynamic client registration without authentication and without redirect URI restrictions. An attacker can register a client pointing to their domain and steal the authorization code of a logged-in victim, then exchange it for access and refresh tokens. The MCP OAuth token carries the victim's full group set in the JWT, and Obot validates only the issuer, not the audience, allowing the token to be used as a bearer token against any Obot API endpoint the victim can access.

obot versions before v0.21.1 fail to enforce Access Control Rules on the /mcp-connect endpoint, allowing any authenticated user to connect to restricted MCP servers if they possess the server ID. Attackers can bypass authorization to access sensitive backend systems.

Obot up to commit d7e6970, when started via the Docker quickstart from README, listens on 0.0.0.0:8080 with authentication disabled. Every request is mapped to a synthetic 'nobody' user with Owner and Admin roles, granting full administrative access. The quickstart also mounts /var/run/docker.sock, giving access to the host's Docker control surface.