CVE-2026-103758

Obot 0.26.0 before 0.26.2 contains an authorization bypass vulnerability that allows authenticated users matching any vMCP profile to reach prompts and resources of ungranted components. Because profiles were enforced only on tools, attackers can access prompts, resources, and resource templates through the vMCP owner's shared component connection.

Obot 0.12.0 before 0.26.2 contains an insufficiently protected credentials vulnerability that allows authenticated users to read static secrets set on MCP catalog entries by admins or power users. Basic users granted an entry by access control rules can request GET /api/all-mcps/entries/{entry_id} to obtain plaintext API keys or tokens and abuse them against backend services.

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.

Obot before 0.26.0 contains an authentication bypass vulnerability in the CLI login flow that allows unauthenticated attackers to steal API keys by choosing token request IDs. Attackers can create a token request via POST /api/token-request, send the login link to a signed-in user, and fetch the resulting non-expiring API key to take over the victim's account.

Obot 0.25.0 before 0.25.6 and 0.26.0 before 0.26.1 contains a race condition in auth provider group refreshes that can restore group memberships just revoked in the identity provider. When overlapping refreshes for the same user commit out of order, stale memberships are persisted and the user retains revoked group-based access for about ten minutes.

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.