This allows any attacker with network reach to the exposed port to gain full administrative control over the Obot API and UI. Furthermore, the quickstart documentation instructs users to mount the host's /var/run/docker.sock into the container. Attackers gaining administrative access through the Obot interface can leverage this mounted socket to interact with the host's Docker engine, potentially leading to container breakout and full host system compromise. The issue is addressed by updated documentation that mandates enabling authentication via the OBOT_SERVER_ENABLE_AUTHENTICATION environment variable.

Impact

Successful exploitation allows unauthenticated remote attackers to gain full administrative access to the Obot platform. Due to the mounting of the host Docker socket, an attacker can escalate privileges from the application level to the host operating system. This vulnerability affects any deployment that followed the standard quickstart instructions without manually overriding the default authentication settings.

Recommendation

Prioritize securing Obot deployments immediately following the documentation update.

• Set the environment variable OBOT_SERVER_ENABLE_AUTHENTICATION=true for all existing Obot containers.
• Review network perimeter controls to ensure the Obot UI and API (port 8080) are not exposed to untrusted networks.
• Verify container mounts to ensure that sensitive host resources, specifically /var/run/docker.sock, are restricted or removed if not strictly required for platform functionality.
• Audit existing Obot logs for unauthorized API access or registry of external MCP servers occurring from unknown or unauthorized client IP addresses.