Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-27T21:17:02.027Z",
  "pubdate": "2026-09-27T21:17:02.027Z",
  "executiveSummary": "Obot, an AI agent and MCP platform, is vulnerable to an authentication bypass condition that grants unauthenticated remote attackers full administrative privileges. This vulnerability exists in all versions up to and including commit d7e6970 due to a default configuration that disables authentication in the Docker quickstart deployment method.\nBy default, the platform binds to 0.0.0.0:8080 without security controls. Consequently, any network-adjacent actor can access the Obot API and UI. Because the system maps unauthenticated requests to a synthetic 'nobody' user granted 'Owner' and 'Admin' roles, an attacker can fully control the platform.\nThe risk is significantly exacerbated by the inclusion of the host's /var/run/docker.sock within the container mount. This provides an attacker with the ability to escape the container context and interact directly with the host's Docker daemon. The primary impact is total compromise of the Obot application and potential host-level system takeover via the exposed Docker control surface. This is a critical security risk for any deployment exposed to untrusted networks.",
  "technicalDetails": "The root cause of this vulnerability is a design flaw in the default configuration settings provided in the Obot documentation for containerized deployments. In all versions up to and including commit d7e6970, the Docker quickstart command instructs users to run the container with settings that explicitly disable authentication mechanisms.\nWhen authentication is disabled, the Obot backend logic defaults all incoming requests to a synthetic user identity identified as 'nobody'. Crucially, the platform assigns this identity 'Owner' and 'Admin' roles, granting unrestricted access to all API endpoints and UI management functions. This includes the ability to register, configure, and execute arbitrary MCP (Model Context Protocol) servers.\nThe attack flow begins with the attacker identifying a target Obot instance exposed to a network. By accessing the web interface or API on port 8080, the attacker bypasses all access control checks. Because the platform provides administrative rights by default to the 'nobody' user, the attacker can immediately manipulate system settings and deploy malicious agent payloads.\nThe exploitation path transitions from application-level compromise to host-level impact due to the common practice of mounting the host's /var/run/docker.sock into the container. This mount is designed to allow the Obot container to manage agent containers; however, because the attacker has administrative control over the Obot application, they can use the application's functionality to interface with the Docker daemon. This allows the attacker to spawn new containers with elevated privileges, mount sensitive host directories, or execute code directly on the underlying host operating system.\nThe vulnerable component is the Obot authentication middleware and the associated container orchestration documentation. No specialized exploit tools are required, as standard HTTP requests to the API or UI are sufficient to achieve full platform takeover. There are no authentication or privilege requirements for the attacker, and the network exposure is broad, as the default configuration binds the service to the 0.0.0.0 interface, making it reachable by any entity capable of routing to the host's IP address."
}