CVE-2026-101065
CriticalCVSS 9.8Summary
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.
Risk Assessment
Unauthenticated attackers can gain full control over Obot and the Docker host, potentially leading to system compromise and malicious container deployment.
Recommendation
Enable authentication (OBOT_SERVER_ENABLE_AUTHENTICATION=true) and avoid exposing the host to untrusted networks without proper security.
Other vulnerabilities in Obot
See all- CVE-2026-101064High
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.
- CVE-2026-101063Medium
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.
- CVE-2026-101062High
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.
- CVE-2026-101084Critical
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.
Original NVD description (English source)
Obot is an open-source AI agent/MCP platform. In all versions up to and including commit d7e6970, the Docker quickstart command documented in the README starts the container listening on 0.0.0.0:8080 with authentication disabled by default. When authentication is disabled, every request is mapped to a synthetic "nobody" user that holds the Owner and Admin roles, so any unauthenticated party who can reach the exposed port obtains full administrative access to the Obot API and UI, including the ability to register and launch attacker-controlled MCP servers. Because the quickstart also mounts /var/run/docker.sock into the container, the MCP runtime backend reachable this way has access to the host's Docker control surface. The fix is documentation-only: the quickstart now enables authentication, and operators who followed the previous instructions should set OBOT_SERVER_ENABLE_AUTHENTICATION=true before exposing the host to any untrusted network.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS